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Preface 


Document Organization 


Prerequisite Publications 


This manual describes how to install, operate and use an NJE (Network Job 
Entry) network. It is written primarily for the systems programmer, but also has 
material for NJE operators and users. While oriented towards JES2, connections 
with JES3, RSCS and POWER are also discussed. 


This is not intended to replace, but merely add to existing product documenta- 
tion. See Appendix C, “Bibliography” for a complete set of references. 


This manual 1s organized into: 
Chapter 1, “Introduction.” An overview of network job entry (NJE). 


Chapter 2, “Systems Programmer’s View of NJE.” How to design, implement 
and manage NJE systems and networks. 


Chapter 3, “Operator’s View of NJE.” How to operate NJE systems and net- 
works. . 


Chapter 4, “End-User’s View of NJE.” How to use NJE facilities. 


The material for Operations and Use of NJE should be adapted to individual 
installations before it is given to operators or end-users. 


Appendix A, ‘Sample Networks.” 
Appendix B, “NJE Flashes.” 
Appendix C, “Bibliography.” 
Appendix D, “Glossary.” 


“Tndex.” 


See the list of required and related publications in front of Chapters 2, 3 and 4. 
Also see Appendix C, “Bibliography.” 
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Concepts and Terminology 


NJE Functions 


Network Job Entry or “NJE” is a facility that provides access to computing facili- 
ties from other host systems. It enables users to transfer work and data 
throughout a distributed network of computing facilities. This bulletin describes 
the features of IBM products supporting these capabilities and gives some insight 
into how these products may be combined to support the computing require- 
ments of an enterprise. 


NJE can be defined as a facility designed for transmitting jobs (SYSIN or 
SYSOUT), operator commands and operator messages, and job accounting infor- 
mation from one computing system to another. In practice, the SYSOUT format 
is used to transmit files, messages and other data objects that are not directly job 
output. See “Uses of NJE” on page 1-5 and “File Transmission” on page 4-39. 


An NJE network 1s a collection of peer-coupled systems connected by communi- 
cation links. A “link” may be a teleprocessing line, channel-to-channel adapter, 
or channel-attached communication controller. Any member of an NJE network 
can send jobs, job output (SYSOUT), commands and messages to any other 
member of the network. 


NJE nodes can support one or more of the three functions: transmit, receive and 
store-and-forward. 


The transmit function consists of packaging SYSIN or SYSOUT jobs in NJE 
Control Records and inserting them into the network. 


The receive function recognizes jobs packaged in NJE Control Records and proc- 


esses them. For example, SYSIN jobs may be executed at that node or SYSOUT 
jobs may be pninted. 
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The receive function recognizes jobs packaged in NJE Control Records and proc- 
esses them. For example, SYSIN jobs may be executed at that node or SYSOUT 
jobs may be printed. 


A node having the store-and-forward function, receives NJE jobs, stores them on 
spool and forwards them to the next node. 


Generally, all nodes must store and forward any data that is imbedded in NJE. 
When the data reaches its destination, it may or may not be processed as the user 
intended, depending on the facilities available at that node. NJE protocols allow 
the destination node to reject files that it cannot process or perform other system- 
dependent actions. 


There are three data types. The first and most common type is a job which, in 
NJ terminology, may be either a SYSIN or SYSOUT stream. Throughout this 
document the term job will be used if no distinction 1s required. If a distinction 1s 
necessary the term SYSIN or SYSOUT will be used. SYSIN 1s that data being 
transmitted to a system for execution at the system. SYSOUT is generally 
output from a program intended to be printed, punched, or viewed at a terminal. 


The second type of data is commands and messages. In NJE, they are trans- 
mitted as nodal message records (NMRs). In the case of commands, the text is 
intended to be executed on the receiving node. Messages are intended to be dis- 
played on the receiving system. NMRs are not stored and forwarded through the 
JES2 spool. Ifa path does not exist to the next node, the NMR 1s discarded. 


The third type of data is network control records. These include signon,signoff 
and path manager (NPM) records. The network path manager is presently only 
implemented in JES2 and allows each node in a JES2 complex to keep track 
dynamically of the path between itself and every other node in the network. In a 
complex network (one with multiple paths between two or more nodes) the 
network path manager is able to recover dynamically from a line or node failure 
and reroute traffic via an alternate path. 


Path Management: JES2 has a network path manager which can keep a real- 
time topological view of the network by sending and receiving add and subtract 
records to other path managers. None of the other products have path managers; 
they rely on operator commands to update the route tables to reflect changes in 
the conncctions in the network. 


For other definitions relating to NJE, see Appendix D, “Glossary” on page D-1 
at the end of this publication. 


A good overview of NJE can be found in [BM Systems Journal V. 17, No. 3 
(1978) containing an article on ’NJE’. Reprints of this article may be ordered by 
the IBM form number G321-5071. For other reading material on NJE, please 
see Appendix C, “Bibliography” on page C-1 at the end of this publication. 


NJE Products 


MVS/JES2 Environment 


MVS/JES3 Environment 


VM/SP Environment 


VSE Environment 


NJE is supported by JES2, JES3, VM/RSCS and VSE/POWER (and by some 
non-IBM program offerings.) In this publication, reference to a particular sub- 
system or operating system implies the latest available level unless specified other- 
wise. All levels are NJE-compatible with one another. 


See “Summary of NJE Features” on page 1-4 for a brief comparison. 


All current releases of JES2 support NJE: 


MVS/SP JES2 Version | Release 3.4, or Version 2 Release 1.2 
MVS/SP JES2 Version | Release 3.6 

MVS/SP JES2 Version 2 Release 1.5 

MVS/SP JES2 Version 2 Release 2.0 (available third quarter 1987) 


JES2 NJE supports BSC, CTC and SNA connections. 


The current releases of JES3, which all support NJE are: 


e MVS/SP JES3 Version | Release 3.4, or Version 2 Release 1.2 
e MVS/SP JES3 Version 2 Release 1.5 
e MVS/SP JES3 Version 2 Release 2.1 (available forth quarter 1987) 


All levels of JES3 support BSC and CTC connections. With the SNA/NJE 


enhancement feature, MVS/Bulk Data Transfer (MVS/BDT) Version 2 may be 
used to support SNA sessions for NJE. 


All current releases of RSCS Networking support NJE: 
e RSCS Networking Version | Reuse 3 

RSCS Networking Version 2 Release 1 

RSCS Networking Version 2 Release 2 


All levels of RSCS support BSC and CTC connections. RSCS Networking 
Version 2 also supports SNA sessions. 


VSE/POWER Version 2 supports NJE with the following current releases: 
e VSE/POWER Version 2 Release 1 

e VSE/POWER Version 2 Release 2 

e VSE/POWER Version 2 Release 3 (available mid-1987) 


All levels of POWER Networking support BSC and SNA connections. Version 
2 Release 3 offers Virtual CTC support utilizing the Virtual CTC support of VM. 
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The following table is provided as a summary chart showing which features are 
supported by the various products. The features shown are arbitrary and are 
neither meant to show any “subsets” of NJE, nor which features are optional. 


Note: The BDT column refers to MVS/BDT in a JES3 environment. 


Feature JES2 JES3 RSCS POWER 
BSC Communications Yes Yes Yes Yes 
SNA Communications Yes No(B) Yes Yes 
CTC Communications Yes Yes Yes Vir.(2.3) 
Network Path Manager Yes No No No 
Formatted Commands Yes (A) (A) No 
Data Compaction Yes No No (A) 
Output Fan-Out Yes (A) (A) (A) 
Spanned Headers Yes Yes Yes Yes 
Multiple Streams Yes Yes(1) Yes Yes 
Parallel Links Yes(BSC) Yes(3) No No 
Multiple Concurrent Paths Yes No No No 
Alternate Path Routing Yes Yes Yes Yes 

Key 

Yes = Supports the Feature 


No = Does Not Support The Feature 

(A) = Accepts, but does not Send 

N/A = Not Applicable 

(J3) = Function Supported by JES3 

(B) = Function Supported by BDT 

(2.3) = Virtual CTC Support in POWER 2.3 

(1) = JES3 supports one SYSIN and one SYSOUT stream in parallel. 
(2) = BDT supports up to 28 virtual LUs (streams) in parallel. 

(3) = JES3 supports up tp three links in parallel - all BSC or all CTC. 


Figure 1-1. 


Features Supported by NJE Products 


BDT 
No(J3) 
Yes 
No(J3) 


No 


N/A(J3) 
No 


N/A(J3) 
Yes 


APAR numbers in this document are current at the time of publication. Consult 
with the IBM Support Center for the latest status in case these APARs have 


been superseded. 


Uses of NJE 


To move jobs 


To move job output 


To assist migration 


Peer-group communication 


NJE can provide a means for users to take advantage of batch computing facili- 
ties at geographically remote locations. 


e NJE can be used to transmit jobs to the system containing the data sets or 
data bases required for job processing. 


e NJE can be used to move jobs to systems with the available processing 
resources. Perhaps the processing power of a 3090 is available in the 
network. This is a simple form of manual workload leveling across nodes in 

an NJE network. 


e NJE can be used to move jobs to systems with the special hardware features 
such as emulators, or vector processors. 


e NJE can be used to move jobs to specific application processing centers. In 
this way, a customer may be able to justify a licensed program product for an 
entire corporation, while it could not for an individual site. 


e The most obvious reason for transmitting SYSOUT data sets is to get them 
to their appropriate locations, closer to the end users. 


e NJE can be used to move SYSOUT to available print or punch resources, 
such as the printing power of an IBM 3800 pnnting subsystem. 


e SYSOUT data sets may be sent to a special output device such as a plotter 
or a microfiche printer. 


The ability to connect systems together can provide a migration aid. Systems 
running VSE, OS/MVS, and VM/37. can all be tied together in a compatible 
NJE network. In this way, jobs can be entered into any system in the network 
and can be either run on the “old” system (for production jobs not yet con- 
verted), or on the “new” system (for testing or production jobs that have been 
converted). In a JES2 Multi-Access Spool environment, the complex can be split 
into two complexes connected by NJE and migrated to a new release of JES2 in 
a smooth and orderly fashion. 


Through NJE and electronic mail, users on the network can communicate with 
one another by sending messages and files between related work groups. This is 
the most common use of the IBM internal job network (called “WNET”) which 
has become an extremely fast, easy-to-use, and valuable tool for communication 
within the company. WNET currently consists of more than 2000 processors 
connected in a world-wide network. 
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In addition, there are several large multi-establishment NJE networks outside of 
IBM, such as BITNET, NETNORTH (in Canada) and EARN (in Europe) 
which use NJE heavily for message routing. 


A system running VM/370 for interactive program development may be con- 
nected to remote processors running MVS. With this kind of a “mixed” or 
“hybrid” NJE network, batch work may be sent to the MVS machine, while 
keeping the VM system available for interactive use. This configuration may also 
be used for remote program testing and maintenance in supporting turn-key 
systems at remote sites. 


In another mixed network, front-end processors for specific applications (e.g., 
CADAM) may be supported by larger batch processing systems. The batch 
systems may be used for large file storage and maintenance and large compute- 
bound jobs, while the smaller front-end processors can respond to a real-time or 
interactive workload. 


NJE may also be used to transfer the contents of spool during a migration. 
A distributed data processing network can be used to centralize and coordinate 


batch computing for an entire enterprise or corporation. NJE is an easily imple- 
mented and immediately useful vehicle for accomplishing this function. 


There are alternative facilities to NJE for transferring jobs and data between 
batch operating systems. See “Alternatives to NJE” on page 2-21 for details. 


e Shared Spool or Multi-Access Spool (MAS) 


Spooled Readers and Wniters under VM 


RJE and Workstation Programs 


e Data Transmission Programs! 


Physical Transportation Mechanisms 


l See also “File Transmission” on page 4-39. 
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The systems programmer’s role in network job entry is one of designing, imple- 
menting and managing the network. This chapter identifies the general tasks 
involved and provide installation tips for the various NJE products. 


The systems programmer is also involved with providing guidance to operators 


and end-users at the installation. Therefore, the following chapters in this publi- 
cation are also for their use. 
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The following publications are the minimum required set for NJE systems pro- 
grammers. Where multiple form numbers are referenced, ensure that you have 
the appropnate one for your installation. See Appendix C, “Bibliography” for a 
more complete list. 

General 


@ NJE Concepts and Protocols Overview, GG66-0224 
e NJE Formats and Protocols, GG22-9373 


MVS/SP-JES2: 


e JES2 Initialization and Tuning, SC23-0046 (Ver. 1) or SC23-0065 (Ver. 2) 
¢ How JES2 Uses SNA for RJE and NJE, GG22-9378 


In addition, the self-study class “JES2 Communications” (SRA course code 
32179) should be considered for JES2 NJE systems programmer education. 


MVS/SP-JES3 
@© JES3 Initialization and Tuning, SC23-0041 (Ver. 1) or SC23-0059 (Ver.2) 
MVS|BDT (Ver. 2) 


© MVS/BDT Installation, SC23-0224 
© JES3 SNA/NJE Installation Considerations, GG22-0253 


VM/RSCS (Ver. 2): 

¢ RSCS Networking Planning and Installation, SH24-5057 
¢ RSCS Networking Operation and Use, SH24-5058 

e RSCS Networking Exit Customization, LY 24-5240 


In addition, the class “"VWM/SNA Networking Facilities” (course code G3610) 
should be considered for VM systems programmer education. 


VSE/POWER (Ver. 2) 
e VSE/POWER Networking User's Guide, SC33-6140 


@© VSE/POWER Installation and Operations Guide, SH12-5329 
@ VSE/POWER Version II Networking Design Guide, GG24-1570 


Network Design 


SNA vs. BSC 


Topologies 


Before designing a network, you should determine the users, uses and require- 
ments of the network. You should also determine how the network is to be 
implemented and managed. A good document for assisting the designers in this 
effort is the Network Management Policy Development Guide (GG22-9285). 


Design Objectives: Consider the following when designing a network: 


Cost 

Performance (Overhead, Throughput and Response Time) 
Availability and Recovery 

Security and Auditability 

Flexibility 

Manageability 

Serviceability 


Pure cost savings might indicate that you minimize the number, speed (and pos- 
sibly reliability), and redundancy of the network connections. These consider- 
ations must be balanced with the benefits associated with the other objectives 
listed above. 


With BSC NJE, the logical and physical configurations are similar. With SNA 
NJE, the logical and physical configurations can be quite different from an NJE 
routing perspective. In the diagram below, Node 1 can have a direct session with 
Node 3 even though there is no direct line between them. To the NJE subsys- 
tems, it appears as though they are directly connected. ACF/VTAM and Multi- 
Systems Networking Facility (MSNF) accomplish this connection through the 
communications controllers (cc) and the network control programs (NCP) trans- 
parent to the NJE subsystems. 


Network topology is the physical and logical configuration of host systems and 
their interconnections. The physical topology is determined by the attachment of 
host processors, communications controllers and lines, as well as other intercon- 
necting mechanisms such as channel-to-channel adapters or shared DASD. The 
logical topology is primarily determined by the various routing tables in the host 
and controllers. The following three figures show various topologies in network 
configuration. 
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4-Node with Full 
Connectivity 


2-Node with 
2 Parallel Links 


Figure 2-1. Simple Network Topologies 


The SNA session can be configured in several ways: 


Over one or more SDLC lines through a pair of communication controllers, 
Over multiple SDLC lines through intermediate communication controllers, 
Through a communication controller channel attached to two systems, 
Through a CTC controlled by ACF/VTAM, or 

Through VTAM between two copies of JES2 in the same processor. 


mA WN = 


In the first two cases, each SDLC line can actually be multiple lines defined as a 
single transmission group. In the first three cases, a communications controller 
running the Network Control Program (NCP) or Partitioned Emulator Program 
(PEP) is required with the appropnate line, physical and logical units defined. 
The last case requires no communication controller or lines and 1s usually used 
for testing. 


Complex Configurations 


SDLC 
(1) SDLC line(s) and Comm. (2) Multiple SDLC Lines and Controllers 
Controller w/2—channel adapters 


N1 | N2 
JES2 | JESA 


VTAM 


(5) Intra—Domain 
NJE Session 


Comm. Controller (4) VTAM-Controlled 
w/2-—channel switch CTC or 3088 


Figure 2-2. SNA NJE Configuration Options 


A large number of nodes and links are hard to manage. Too many links are 
expensive. In a large network, it is not practical to have a physical link between 
every pair of nodes. Even if the nodes all support SNA sessions, it may not be 
worthwhile to have a logical session between every pair of nodes, especially since 
NJE supports store and forward traffic. 


When designing a new network for NJE, a good starting point is to use existing 
teleprocessing links or corporate organizational boundaries in structuring the 
network. 


Subnets with Gateways: As networks:grow in size and complexity, and multiple 
networks are interconnected, it becomes practical to manage them 1n pieces with 
a limited numiber of control points. For this reason, large NJE networks should 
be broken up into “subnets” with “gateway” nodes providing the interconnection 
of these subnets, as the figure below portrays. Where multiple enterprises are in 
the same NJE network, use gateways for security, accounting and control. 
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Sub-Net "A" Sub-Net "B" 


Figure 2-3. Gateway Configuration 


Back-Bone Network Configuration: As the number of subnets and intercon- 
nections grow, the concept of a “hub” or “back-bone” becomes useful in man- 
aging the interconnection and NJE traffic. The figure below shows three subnets 
“A”, “B” and “C” connected through gateway nodes ”“A5”, ”“B3” and “C3” which 
comprise the back-bone of the network. 


Sub-Net "A" 


BS] Sub-Net “B" 


cS Sub—-Net "C" 


Figure 2-4. Back-Bone Network Configuration 


Combining Multiple NJE Networks: The concept of gateways is also key in 
combining multiple NJE networks. See “Secure Network Boundaries” on 
page 2-16. 


Multiple Time Zones 


Systems supporting NJE must communicate with operators, end users and 
systems management records using local time references. Communications 
between NJE systems, however, use GMT (Greenwich Mean Time) or Universal 
Standard Time values to handle multiple time zones. All tume and date stamps in 
NJE headers are expressed in GMT references. 


For this reason, it is important to initialize your system with the correct GMT 
offset. 


MVS JES2 and JES3: Failure to keep the TOD (Time Of Day) clock in correct 
GMT time in an NJE network spanning multiple tume zones will create incorrect 
time stamps in SMF records, and prevent the JES2 path manager from recog- 
nizing nodal connections. 


When the system is IPLed, the TOD Clock should always be set with the correct 
offset from GMT. The offset of the local system is determined at system initial- 
ization by the PARMTZ member in PARMLIB. Do not attempt to change the 
TOD clock after initialization with the SET CLOCK or SET DATE command. 
The system must be re-]PLed to correct or change the clock. 


RSCS: With RSCS Version 2.2, the tume zone parameter is no longer supported 
on the LOCAL or LINK statements. The offset of the local system is deter- 
mined at system generation time by the SYSTIME macro which is part of 
DMKSYS. With NJE headers, it is not necessary to know the offset of other 
systems because all time stamps are in GMT. 


Chapter 2. Systems Programmer's View of NJE 2-7 


Naming Conventions and Terminology 


NJE Addressing 


SNA LU Names 
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NJE uses a 2-level addressing scheme: a 1- to 8-character node name and an 
optional 1|- to 8-character remote workstation, a program or a userid name. 


Node Names: Pick node-names that will never have to change. Otherwise, the 
entire network will have to be synchronized, and end-users and operators will 
have to be notified to use the new names and change their JCL. See “Changing 
Node Numbers or Names” on page 2-42. 


Nodes are identified by a 1- to 8-character alphameric name. In JES2, the default 
node name is of the form ’Nnnnn’ without leading zeros, but we recommend 
using more descriptive names. Although node names, not numbers, are used for 
all NJE system-to-system communication, JES2 stores node names (and RJE 
workstation identifiers) internally as a binary number. 


Userids: These may refer to TSO users (1- to 7- characters), VWM/CMS users or 
program names (1- to 8-characters). 


Program Names: Like remote workstations and userids, these are the second 
level of NJE destination naming and may represent an interactive subsystem like 
CICS or IMS. 


JES2 Addressing: JES2 supports up to 1000 nodes and 4000 remotes (RJE 
stations). Remotes and nodes are defined during JES2 initialization. These defi- 
nitions can only be changed by a warm-start of JES2. Through a trivial modifi- 
cation to JES2, the $MAXNODE equate may be changed to support over 4000 
nodes (and JES2 re-assembled). 


JES3 Addressing: ‘here is no limit to the number of nodes or remotes that can 
be defined to JES3. For MVS/BDT, however, only 99 directly-connected SNA 
nodes can be defined. 


These names are not referenced by users for NJE destination routing. They are 
usually the same as the Node Names, but they don’t have to be. If there is more 
than one system in a node participating in the NJE network using SNA (e.g., a 
JES2 MAS node), then some names would be different to maintain uniqueness in 
the SNA network. 


Consult with your SNA Network Coordinator to ensure unique names throughout 
the network. 


System Identifiers 


Network Standards 


All members of a multi-access spool configuration have the same node name in 
the network. Particular members can be identified by a system-id or member 
number. NJE protocols do not allow jobs or SYSOUT data sets to be routed to 
specific members of a MAS complex. The JES2 control card /*JOBPARM or 
class structures can be used to select a particular system. (In JES3, the equivalent 
information can be specified on the //*MAIN card.) Messages and commands, 
however, can be routed to a particular member on an NJE node. 


Systems programmers should be involved in establishing NJE (network-wide) 
standards for end users and operators. These standards should be designed, docu- 
mented and tested before the network is implemented. See “Execution Node 
Requirements” on page 4-16 and “Output Node Requirements” on page 4-28 
for input. 
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Parallel Links 
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The network 1s available for useful work only if the sending node, the destination 
node, and an active path between the two are all working and available. There- 
fore, it is umportant to plan for availability when designing a network. 


Availability can be designed into the network by increasing the reliability of each 
of the parts, minimizing the number of serially-dependent parts, and providing 
alternate paths. (Weigh the cost and complexity of these objectives against the 
value of increased availability.) 


Some observations about network availability: 

e Digital links are more reliable than analog links. 

e Channel-to-channel adapters are more reliable than common carmiers. 

e Direct lines are better than indirect connections. 
Direct lines between every pair of nodes that have files to send to one 
another will maximize the availability, minimize the overhead and shorten the 
transmission time. This way, every node can access every other node without 
relying on intermediate nodes. 


e Parallel links between adjacent nodes provide greater availability 


Multiple parallel links provide greater availability than a single link if they use 
different physical circuits. 


e Alternate paths through other nodes provide for alternate path routing should 
the primary path become unavailable. 


e SNA Networks have several advantages over BSC Networks including the 
ability to share lines with other applications, better recovery, and perform- 
ance (especially over satellite links). 


See also “Availability and Recovery” on page 2-41 for network management 
comments. 


JES2 supports an unlimited number of parallel BSC lines connecting two nodes. 
With SNA, multiple SDLC lines can be configured in a transmission group in 
ACF/VTAM to provide another level of redundancy. 


JES3: Zero to three lines can be defined for each directly connected node 1n the 
network, as long as they are all of the same type (1.e., all BSC, or all CTC). 


RSCS and POWER: Parallel links are not supported. 


Multiple SNA Sessions 


JES2 theoretically only supports one SNA session between two JES2 systems. 
With multi-access spool, however, multiple sessions can exist between a pair of 
nodes by having more than one system in a node start a session. 


Figure 2-5. Parallel SNA NJE Sessions With Nfulti-Access Spool 


Second Session Between Two JES2 Systems: Another way to have two parallel 
sessions between two nodes follows: 


LOGON1=Al LOGON1=B1 
LOGON2=A2 LOGON2=B2 
Node A Node B 


Session 1 
APPLID=Al APPLID=B2 


APPLID=A2 APPLID=B1 
Session 2 


Figure 2-6. Parallel NJE Sessions With Multiple LOGONs (ACBs) 


See “Second Session Between Two JES2 Systems” on page B-2 for details. 


Multi- Access Spool Considerations 


JES2 multi-access spool (MAS) nodes can either have all NJE connections on 
one member, or spread them over the complex. In either case, you may want to 
switch these connections to back-up a failing processor or communications con- 
troller. If the connections are to other JES2 nodes (and they are not pre-defined 
at either end), then the path manager will adjust dynamically to any reconfigura- 
tion. If the connections are pre-defined, then it is more difficult to change the 
member. 


Backing-Up Predefined Connections 


Advantages of pre-defining connections may be offset by the problem that these 
connections cannot be changed without a JES2 all-systems warm-start. Below 
are some techniques for backing up these connections: 


1. Use hardware switches and secondary JES2 subsystems to bring up the 
defined member on another processor. 


2. Use the $;CONNECT function (exit 5) on the SHARE JES2 MODS tape to 
change pre-defined connections with operator commands. 
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3. Define multiple CONNECT statements, one for each combination of 
members that can be connected. A disadvantage to this is that you can’t 
send commands or messages from those members that do not have a real 
connection. 


RSCS Enhancement: Several users have found it useful to modify RSCS to act 
like a JES2 node at sign-on time. There is an RSCS modification on the 
SHARE JES2 MODS tape to eliminate the need for pre-defined connections for 
adjacent RSCS nodes. 


Alternate Path Routing and Network Reconfiguration 
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JES2: The Network Path Manager in JES2 is designed for dynamic reconfigura- 
tion with other JES2 nodes. Multiple paths, alternate paths and path changes are 
managed automatically as connections are made or broken. 


Mixed JES2 and non-JES2 Network: There are some special considerations 
when designing a network with JES2 and non-JES2 nodes: 


e Non-JES2 systems do not have a network path manager to notify JES2 
systems of connection changes in the network. 


e Non-JES2 systems do not forward connection information records sent by 
the JES2 path manager to other nodes in the network. 


¢ Connections between JES2 and non-JES2 nodes must be pre-defined in the 
JES2 node (except in the case where an adjacent RSCS node has the modifi- 
cation mentioned above). 


e Pre-defined connections cannot be changed without a JES2 warm-start 
(unless the JES2 $CONNECT modification mentioned above is used). 


Other Systems: ‘There is no path manager, but the operator can dynamically 
change a path in the network with an operator command. See “Altering Nodes 
and Paths” on page 3-9 for details. 


Security Precautions 


Security precautions must be designed into the network configuration. Some 
understanding of the network use is required to plan for a secure network: 


e Network users: 


— Who are they? 
— Where are they? 
— How are they identified? 


e Resources: 


— What resources are required by the users? 

— What resources need protection? 

— What level of access is required for protection? 
— Where are they? 

— low are they identified? 


From an NJE perspective, the actual mechanisms used to protect the resources 
should be at several levels, including, but not limited to, the following: 


RACF 

Encryption (DES) 

JES passwords 

JES exits 

SAF exits 

SMF exits 

other MVS exits and modifications 


Host System Protection - Job Execution 


RACE is the standard IBM facility used to protect resources from unauthorized 
access to programs and data on MVS and VM systems. RACEF has no “network 
awareness”, but is independent on each system. 


RACE control files must be synchronized across nodes if the same userid 1s to be 
authorized to submit jobs on one node that execute on other nodes. This may 
require a network-wide coordination of userids and groupids. It may also require 
that passwords are updated simultaneously on all nodes. 


User Identification and Verification 


Identification: With MVS jobs, there is a user and/or group identification associ- 
ated with cach job. There is also an ongin node for each job which can be used 
to validate authorization. However, for SYSIN jobs, this field (NJHGORGN) 
can be counterfeited with the 7*NOTIFY statement. 


With JES2, one or two JOB statements can be used. All jobs are verified at the 
execution node. Jobs sent with the 7%XMIT statement have their first JOB state- 
ment verified at the ongin (submitting) node, and their second JOB statement 
verified at the execution node. If the job fails on the submitting node, then obvi- 
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ously nothing 1s transmitted. (Authorization information is not propagated from 
the first JOB statement to the second.) 


Propagation of Userid and Password: With the fix to APAR OZ81051, the sub- 
mitter’s user and group identification are propagated to spawned jobs that will 
execute on the local node. This replaces the password checking at job initiation. 
For spool offload operations, the submitting userid and groupid are now placed 
in the job header. This information is NOT transmitted to other NJE nodes 
without modifying JES2. 


Propagating Userid and Verification Check: JES2 does not propagate the user 
and groupid on jobs destined for another node. However, with a modification to 
HASPNET, you can prevent JES2 from zeroing out the userid and groupid fields 
in the job header at the origin and intermediate nodes. 


At a JES2 execution node, the presence of these fields indicates that the job has 
been verified and bypasses password checking on the execution node. However, 
another check will be made at the execution node to see if the job originated 
from another node, and if so, will force it to go through validation again.' This 
approach avoids having to maintain RACF control information for a user in 
multiple places, and assumes the security of the origin node. The userid must be 
defined on both nodes and have access authorization to the protected resources 
needed on the receiving node. 


Alternatively, a RACINIT exit (on the execution node) can set PASSCHK = NO 
based on the userid so that the password need not be available at the execution 
node. 


Both of these approaches must be evaluated for adequate security in the custom- 
er’s environment. 


Encrypting Transmitted Passwords: When passwords are transmitted in the job 
header, they are sent in clear text. Through the use of user exits or modifications 
to JES, the passwords could be encrypted, so they could not be disclosed during 
transmission. Ether the DES encryption algorithm available with RACF, or the 
old “hashing” routine (available in RACF before DES) can be used. In both 
cases, JES2 exits 2 or 20 can be used or ‘oth the sending and receiving systems. 
For JES3, user exit UX40 can be used on the sending system and UX35 on the 
receiving system. The same encryption key must be used throughout the 
network. 


DES Encryption: Installation-wntten code at the sending node could use the 
RACXTRT supervisor service routine to encrypt the password and place it in the 
Network Job Header. At the execution node, RACINIT pre-processing can use 
the encrypted password “as is”. 


1 See APAR OY04615. 


Command Authorization 


Communication Protection 


Network Access 


Job Transmission Control 


Hashing: The sending node can use the hashing algorithm to encrypt the 
password(s) and place them in the Network Job Header fields (NJHGPASS and 
NJHGNPAS). 


The receiving node uses the decryption (“de-hashing”) algorithm to “unscramble” 
the passwords before JES passed them to the authorization mechanism. The de- 
hashing code can be found on the SHARE JES2 MODS tape or by reversing the 
RACE hashing algonthm. 


It should be the responsibility of the target system to authonze (or deny) any 
commands submitted from other nodes. Part of this authonzation checking 
includes validating the source of the command. This 1s especially true of user 
commands implemented in JES2 exit 5. If the source is from an unsecured part 
of the network, then all but the most “tame” (e.g., display) commands should be 
rejected. See “Command Authorization” on page 3-33. 


End-to-End Encryption: Cryptographic modems can be used to encrypt teleproc- 
essing lines. 


With ACF/VTAM, use either the Programmed Cryptographic Facility 
(5740-XY5) or the Cryptographic Unit Support (5740-XY6) to encrypt the 
session. 


File or Data Encryption: AMS facilities with either the Programmed 
Cryptographic Facility (5740-XY5) or the Cryptographic Unit Support 
(5740-X Y6) can be used to encrypt the sensitive data sets before transmission. 


JES2 Sign-on Authentication: NJE provides two sets of passwords for 
authenticating the connection at sign-on time: Node and Line passwords. Line 
passwords can only be used on BSC NJE lines. 


In addition, VTAM can require a password for the ACB which is coded on the 
JES2 LOGONn initialization statement. 


Job’s SYSIN can be validated at the submitting node, and again at the node of 
execution, but it is hard to control the transmission of jobs throughout the 
network once they have been submitted. 


Because JES2 reader exits are not invoked for intermediate nodes, JES2 may have 
to be modified at gateway nodes to implement sufficient checking for all jobs 
entering the “secure” subnet. 


It also may be necessary to prohibit (through VTAM parameters) SNA sessions 


which bypass the gateway hosts, so that the gateway becomes an intermediate 
NJE node for all jobs. 
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Other Data Flow Control 


SYSOUT Data Transmission: SYSOUT data is not protected by normal RACF 
controls while it 1s on the subsystem’s spool. If systems in the network handle 
highly sensitive SYSOUT data, your installation should set up a scheme to iden- 
tify these files and control their transmission out from the authorized sphere of 
nodes. You can do this with job name, SYSOUT class, forms ID or some other 
output attribute. 


Command Transmission: While it 1s still the responsibility of the target system to 
authorize commands submitted from other nodes, gateway nodes may want to 
check in-coming commands for source and type of command. Unfortunately, 
this cannot be done without a modification to the JES2 HASPCON source 
module (near label WWQUE). 


Message Transmission: There is no way to control the flow of messages coming 
into or going out of a JES2 system, without modifying JES2 code. However, 
there is little security exposure in allowing all incoming or outgoing messages. 


Control Information Transmission: YYou may also want to control sensitive infor- 
mation such as node names, remote names and user-ids, especially in networks 
interconnected with other organizations. See ‘Secure Network Boundaries” for 
details. 


Secure Network Boundaries 
Some partitioning of the network may be required to isolate or control indiscnm- 
inate access throughout the network. This is especially true when connecting two 
enterprises via NJE. Implement gateways at the boundaries of these subnets to 


authorize jobs, output, commands and messages entering the secure partition. 


Usually, the NJE network is configured as follows: 


me ee oe ee + eae a ae wwe — 
| +--------- + +--------- + | 
Our {==[ Our l[---7 | Other’ |==| Other 
Network |==| Gateway | /---| Gateway |==| Network 
| ==| Node | ; Node | ==] 
| t--------- + $t—--------- + | 
ee eee ee + a ae es 


Referring to the above diagram, possible security precautions might include the 
following: 


Validate and secure the connection between the two gateway nodes. 
Don’t let the other gateway know about our nodes. 

Restnct knowledge about the gateway on our nodes. 

Control Job (and SYSOUT) transmission to and from the other gateway. 
Control Commands (and messages) coming from the other gateway. 


Ve Pe YS 


The corresponding solutions to these requirements are discussed below: 


2-16 JES2 NJE 


Validate and secure the connection between the two gateway nodes 


e Restrict the connection to a single gateway node (and system) on both sides 
of the connection. 


e Use JES2 NJE node (and line) passwords. 
e Secure the connection physically or with encryption if necessary. 


Don't let the other gateway know about our nodes: Control NCC (Network 
Connection and Control) Add (M) and Subtract (N) records about our network 
from flowing from our gateway to the other gateway: 


e Pre-define our network connections on our gateway node. NCC records do 
not get sent about pre-defined connections. This does not allow back-up or 
re-configuration. See “Backing-Up Predefined Connections” on page 2-11 
for solutions to back-up pre-defined connections. 


e If pre-definition is not possible, modify JES2 (NPM) on our gateway to 
prevent any NCC (M and N) records from going to the other gateway. 


e Puta VM node between the two gateways. (This is rather drastic, but keeps 
the NCC records from flowing to the other network.) 


Restrict knowledge about the gateway on our nodes: WDefine the other gateway 
node only where access is required and can be controlled. Also restrict NCC (M 
and N) records from flowing to our nodes. 


e Pre-define the gateway connection. This does not allow back-up or re- 
configuration. Sce ‘“Backing-Up Predefined Connections” on page 2-11. 


e If pre-definition 1s not possible, it may be necessary to modify the JES2 Path 
Manager (NPM) on our gateway to prevent propagation of NCC records to 
other nodes. 


Control Job (and SYSOUT) transmission to and from the other gateway: 
Control Jobs (including SYSOUT) from being transmitted to “our” network from 
the “other” gateway: 


e Use RACF on our nodes to control job execution. SYSOUT 1s not con- 
trolled, but less of a nsk. 


e If necessary, use JES2 exits or modifications to the Job and SYSOUT 
Receivers on our gateway to screen all jobs coming from the other gateway. 
Be aware that the fields in the job header (NJHGORGN and NJHGORGU) 
which identify the origin of the job can be changed by the /*NOTIFY 
control statement and may NOT reflect the true origin of the job. 


Control Jobs (including SYSOUT) from being transmitted from “our” network to 
nodes in the “other” network: 


e Modify Job and SYSOUT Transmitters (at least on “our” gateway) to screen 
all jobs going to the other gateway. 
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Control Commands (and messages) coming from the other gateway 
e Use JES2 nodal authonty (NONETATH, etc.) 


e Modify the Remote Console Processor to screen NMR transmissions. 
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Performance Considerations 
You must understand the NJE traffic workloads and patterns to design the 
network with adequate performance. In addition to the above considerations for 


availability, answer the following questions when planning for acceptable per- 
formance: 


e What volume of data is to be moved between each pair of nodes? 

e What are the availability charactenstics of the network? 

e What other traffic will exist on the lines? 

e What is the availability of host processors to send, receive and relay this data? 


Provide the capacity to handle increased NJE traffic; NJE usage often increases 
unexpectedly. 


Do not underestimate the impact of NJE work on existing system resources. 
Increased overhead can be significant in JES2 processor cycles, storage, spool 
space and the number of jobs and output elements in the system. The overhead 
of NJE is similar to RJE for equivalent data volumes. 


Intermediate nodes play a critical role in network performance. If the data must 
be stored-and-forwarded between the omgin and destination nodes, then the 
transit time is obviously increased and additional overhead is required. 

If there is a physical connection or SNA session between every pair of nodes, 
then there are no intermediate nodes (unless a line or session breaks). In this 
case, host resources are not required to forward the data through intermediate 
nodes. However, full connectivity can be costly in large networks in terms of 
additional communication resources and operations complexity. If the data 
traffic patterns are known, then a NJE network can be better designed from a 
performance, cost and complexity standpoint. 


Optimizing Performance: ‘The following rules of thumb may help in designing a 
network with optimum performance: 


e Use direct connections to all nodes for which there is significant traffic. 
e Optimize bandwidth based on peak traffic requirements. 

e For local connections, use a CTC or channel attached 37xS. 

e Use SNA instead of BSC, especially over satellite connections. 

e With SNA, intelligent use of pacing parameters is important. 

e Use the maximum size of teleprocessing buffers. 


e Provide, or even dedicate, adequate processor cycles, storage and I/O 
resources to NJE and communications subsystems. 
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e Use multiple sessions or links between NJE nodes. 


e Maximize the availability and redundancy (back-up) of all network compo- 
nents. 


e Minimize the time to repair all components of the network. 
See “Performance Management” on page 2-44 for a more detailed discussion of 


most of these considerations and “SNA _ Performance Considerations” on 
page 2-37 for some specific SNA precautions. 


Alternatives to NJE 


Multi-Access Spool (MAS) 


There are alternative facilities to NJE for transferring jobs and data between 
batch operating systems. 


e Miulti-Access Spool (MAS) 


e Spooled Readers and Wniters under VM 


e RJE and Workstation Programs 


e Data Transmission Programs 


e Physical Transportation Mechanisms 


Two processors in the same building can be connected via Multi-Access Spool or 
by Network Job Entry, but not both. This also applies to JES2 subsystems in 
the same MVS processor. See “Secondary JES2 Subsystems” on page 2-39 for 
details on running secondary JES2 subsystems in a NJE environment. In general, 
we recommend a MAS connection. The following Pro’s and Con’s may help. 


e MAS Advantages 


I. 


Common queue of work for jobs and output - better utilization (load 
balancing) of CPUs and output devices. 


More of a single systems image for programmers and operators. 


No communication line, CTC or shared controller is required; the con- 
nection is made entirely through shared DASD. 


e NJE Advantages 


I: 


There is more isolation between the processors for increased availability 
and security. 


You can connect processors at different levels of JES. 


Processors can be geographically separated. This may help in future data 
center splits and staged data center moves. 


No shared DASD 1s required. 
A very large complex may stress the limits of JES (e.g., size of job queue, 
number of remotes, etc.). This could be alleviated by splitting the 


complex into two (or more) nodes. 


There is a design limit of only seven JES2 processors that can be coupled 
with MAS. 
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Spooled Devices in Virtual Machines 


Remote Job Entry (RJE) 


When running a guest operating system under VM, the connection between the 
guest and the VM system may be either through spooled devices (readers, printers 
and punches), or through NJE (CTC or EP), or both. 


A VM/CMS user’s virtual printer, punch and reader can be spooled to the MVS 
guest. (JES2 exit 1 can be used to separate individual output elements and direct 
them to a specific user.) 


In general, we recommend NJE facilities for transferring files between VM _ users 
and guest operating systems. 


There are workstation programs under VM (RSCS) and VSE (RJE Workstation 
Program) which can make these systems appear as a “sub-host” or remote work- 
station to JES2 (or JES3 or VM or VSE). This was the traditional way of 
loosely coupling systems before NJE was available. These connections are not as 
powerful and were not designed for host-to-host communications on a peer basis. 
The RJE protocols were designed for remote readers, printers and punches. The 
NJE protocols provide a much nicher set of functions such as retaining job and 
output attributes, preserving the onginator’s user-id, and allowing jobs, output, 
messages and commands to flow from any node, to any other node in the 
network. 


Some systems, such as System/34 and the Personal Computer do not currently 
have any NJE facility. For them, RJE and remote workstation programs are the 
best available mechanism to facilitate job and output transfer. There is no IBM 
workstation program which runs on MVS. For additional details on this topic, 
see the WSC Technical Bulletin Job Networking Facilities (GG22-9042). 


Bulk Data Transmission Programs 
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NJE may be used to transmit bulk data. There are also facilities which do not 
use NJE to transmit bulk data. 


1. MVS/BDT 
2. FTP Version 2 
3. DSX 


In general, we recommend NJE for small files. Other data transmission mech- 
anisms are more appropriate for large files, because they can eliminate spooling of 
data at either end, and provide transmission checkpoint/restart. See ‘File 
Transmission” on page 4-39 for more discussion on this topic. 


Physical Transportation Mechanisms 


Don’t forget the old-fashioned method of sending reels of tape through the mail. 
One liability of NJE is that it can be very easy to misuse by sending enormous 
amounts of data to another node’s location. It is very easy to use the TSO 
TRANSMIT or CMS SENDFILE command. The impact on intermediate nodes 
can be devastating if there are no mechanisms to limit the size of files being sent. 
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Network Implementation 


Systems Requirements 


Implementing an NJE network is like implementing a SNA network; it takes 
coordination of names and parameters between the different sites. 


When first installing an NJE connection, begin with a simple network of two 
nodes and let most of the options default. Then, as you add nodes, lines and 
options, you have a much better chance of determining the problem if something 
doesn’t work correctly. 


NJE is an integral function in the current JES2, JES3, RSCS and POWER pro- 
ducts, so no special features are required. 


Communications Links and Controllers 
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For communications with other nodes, you must install and define the appro- 
priate teleprocessing links, channel-to-channel adapters, communications control- 
lers and communications subsystems. 


There are three different ways an NJE connection can be made: via a BSC line, 
a channel-to-channel adapter, or a SNA session. 


BSC: A communications controller running the Emulator Program (EP) or Par- 
titioned Emulator Program (PEP) emulating a 2701 is required with a port and 
UCB address for each BSC line. A real line must exist between the two EP line 
sets. 


JES2 uses “RTAM’ (Remote Terminal Access Method) which is an access 
method internal to JES2. No separate communications access method 1s required. 


Dial Lines: Dial-up lines may be used for NJE, either for BSC or SDLC con- 
nections. There are two basic problems, however: 


e Dhal-up (switched) lines are relative. slow. 
e The connection must be made manually. NJE has no auto-dial facility. 


Channel-to-Channel: A Channel-to-channel adapter (CTC or CTCA), or a 3088 
connection is supported through RTAM simular to a BSC line. They must be 
dedicated to JES2 and cannot be shared with any other application. They must 
be generated (defined to MVS) as unshared UCWs on a block multiplexor 
channel with FEATURE=370 coded in the IODEVICE macro (even though JES2 
operates this in 360 compatibility mode). Also, the TIMEQUT=Y parameter 
should be coded in the IOCP generation. The device should also be included in 
the missing interrupt handler (MIH) list (PECIOSxx) member of Parmlib with a 
3- to 5-minute interval. 


SNA Requirements 


All the NJE products support CTC except POWER.” 


CTCs can also be used by ACF/VTAM, in which case they could be used as a 
SNA link, but this is transparent to JES. 


VTAM: ACF/VTAM is required as the host communications access method. 
See “VTAM Parameters” on page 2-32 for detailed requirements. 


JES2: All current levels of JES2 support SNA NJE. 
JES3: If SNA NJE is required with a JES3 node, the following 1s required: 
e MVS/BDT Version 2 (HBD2103) with feature JBD2111, and 
e either: 
— JES3 1.3.4 (HJS2329) with feature JJS2353, or 
— JES3 2.1.5 (HJS2215) with feature JJS2355. 
RSCS: For SNA connections, Version 2 of RSCS Networking is required. 
POWER: All releases of POWER Networking support SNA (as well as BSC). 
SNA Communication Resources: Depending on the configuration, the proper 


lines, controllers and access methods must be installed, defined and activated for 
NJE use. See “Using SNA” on page 2-4 for configuration options. 


2 _—s*Virtual CTC support has been announced for POWER Networking Version 2.3, 
using virtual CTC links in VM. 


3 ACF/TCAM could be used as an alternative but not addressed in this publication. 
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JES2 Initialization Parameters 


Required Parameters 
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The following parameters for the 2.1.5 or 1.3.6 level of JES2. Most NJE parame- 
ters are not required; the defaults are sufficient, especially for simple networks. 
The minimum set of parameters required on the NJEDEF initialization statement 


for NJE is: 


NUMNODE 


OWNNODE 


LINENUM 


The maximum node number defined to JES2 on the 
NODEnnnn parameters. (The default is one (1) which prevents 
any NJE connections.) This value may be changed on a warm- 
start in JES2 2.1.5 or 1.3.6, but required an all-systems warm- 
start or even a cold-start in earlier releases. 


All NJE network nodes are assigned a number for internal JES2 
processing and for operator commands and messages. This 
parameter defines the number of the node for this particular 
system. Node numbers do not have to agree across JES2 
nodes, but it may help to have them the same to avoid con- 
fusion. Changing this parameter requires a JES2 cold-start (of 
the entire complex), so don’t plan on changing it easily. The 
default is one (1), so if you are using NJE for the first tume, you 
must use | to avoid a cold-start. This parameter must be the 
same on all systems in a MAS complex. 


This is the number of logical JES2 lines for NJE and a subset of 
the total number of lines specified by the LINEnnnn state- 
ments. 


The number of logical lines used for RJE or NJE used to be 
specified with the &NUMLNES parameter, but is no longer 
required with JES2/2.1.5, because JES2 now determines this 
value by the number of LINEnnnn statements. 


In addition, the following statements a required to define the logical lines and 
nodes in the network: 


LINEnnnn 


NODEnnnn 


This is required for each direct BSC and CTC connection and 
for each SNA session to be established with another NJE node. 


Using BSC, lines specify the actual unit address of the BSC 
port. 


While this parameter is not absolutely required, it is recom- 
mended that you specify more meaningful nodenames than 
“N1’, “N2”, etc.. Node numbers do not have to agree across 
JES2 nodes, but it helps to have them the same to avoid con- 
fusion. See section “Default Names” in the chapter on 
“Network Job Entry” in SPL: JES2 Initialization and Tuning 
(SC23-0046 for 1.3.6, or SC23-0065 for 2.1.5) for more dis- 


cussion. 


Required for SNA NJE Sessions 


In addition to the above parameters, if this node is to use SNA NJE connections, 
then the following parameters are also required: 


NODEnnnn SNA must be specified for any node which is to be connected 
via a SNA session. 


LINEnnnn UNIT=SNA is used to specify a logical line for SNA NJE or 
RJE. No other parameters are required. 


With SNA, the operator command to start networking may 
specify a particular line number at the initiating end, but the line 
chosen at the other end, if JES2, is the last available one made 
active. 


LOGONI The APPLID for JES2 NJE sessions initiated from this system 
must be identified with the LOGON1 statement. 


LOGON2 This may be used to define an alternate APPLID for SNA RJE 
sessions, or for NJE sessions initiated from other nodes. See 
‘Multiple Sessions between JES2 Nodes” on page 2-38 for 
more details. 


The number of logical VWTAM application interfaces used to be 
specified with the &NUMLOGS parameter, but is no longer 
required with JES2/2.1.5, because JES2 now determines this 
value by the number of LOGONn statements. 


APPL This is used to define VTAM APPLIDs for other nodes. It is 
required for other SNA nodes that this system is to have an 
SNA NJE session with, whose APPLID name is not the same 
as the node name. 


See sections “Minimum NJE Configuration Parameters” and “Minimum Config- 
uration for SNA NJE” in the chapter on “Network Job Entry” in SPL: JES2 
Initialization and Tuning for a discussion of the required parameters and some 
good examples. 


Conncctions to Non-JES2 Nodes 


CONNECT initialization statements are required if the NJE network is to contain 
non-JES2 nodes.* In addition, any JES2 nodes which are connected through 
non-JES2 nodes must be pre-defined with a CONNECT statement. (This is 
because non-JES2 nodes will not pass the connection information records along 
to other nodes.) 


In the diagram below, Nodel must have the Node3-Node4 connection pre- 
defined (in addition to the Nodel-Node2 and Node2-Node3 connections). This 


: An exception is for adjacent RSCS nodes which have a modification to make them 
act like a path manager node at sign-on time. See “RSCS Enhancement” on 
page 2-12. 
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is because the path management records from Node3 will be thrown away by 
RSCS at Nodez2. 


Nodel Node2 Node3 Node¢ 


Cautions: Make sure the MEMBx parameters are correct or the NJE connection 
will not work. They should be specified as the system identifier (SIDn on the 
MASDEF statement) for JES2 nodes and ‘1’ for non-JES2 nodes. 


If a link to an adjacent node fails, alternate path routing cannot be used if the 
connection is pre-defined. 


The CONNECT statements not only pre-define NJE connections, but makes them 
permanent until the next JES2 restart; they cannot be changed with operator 
commands nor by the path manager.» The CONNECT statement also makes it 
private to this node; the path manager will not propagate the knowledge of this 
connection to other JES2 nodes. 


There may be other reasons for coding CONNECT statements, but they should be 
used cautiously. Excessive or inaccurate use of these statements can cause severe 
and difficult to analyze problems including: 


Performance degradation 

High CPU utilization 

Path manager loops 

Jobs looping endlessly through the network 
Inability to use alternate paths 


See “Predefining Connections” and following sections in the chapter on “Network 
Job Entry” in SPL: JES2 Initialization and Tuning. 


For detailed descriptions of these initialization statements, see J/ES2 Initialization 
and Tuning. 


Multiple Transmitters and Receivers: The following parameters on the NJEDEF 
statement may be used to specify multiple job or SYSOUT transmitters or 
receivers on this system. They apply to all NJE lines (BSC, CTC and SNA) on 
the system and do not have to match the numbers specified on other members in 
the complex nor other nodes in the network. On each NJE line, unmatched 
transmitters and receivers are drained. 


See “Multiple Transmitters and Receivers” on page 2-37 for performance impli- 
cations. 


5 There is a modification to JES2 to allow operators to change connect statements 
(SCONNECT). See “Backing-Up Predefined Connections” on page 2-11. 


JRNUM Number of job receivers on each line 
JTNUM Number of job transmitters on each line 
SRNUM Number of sysout receivers on each line 
STNUM ~ Number of sysout transmitters on each line 


BDT (Version 2), RSCS Networking Version 2 and POWER Networking all 
support multiple transmitters and receivers, but JES3 (BSC) and earlier versions 


of RSCS do not. 


Path Manager Variables: The remaining parameters on the NJEDEF statement 
are primarily used to tune the network path manager parameters and can be left 
to their default values in small or simple networks. 


NATNUM 


PATH 


DELAY 


RESTMAX 


RESTNODE 


RESTTOL 


Number of connections between NJE subsystems 

Maximum number of paths to any given node 

Maximum message delay time 

Maximum path resistance, above which JES2 will not select a 
route. This does not apply to directly attached nodes or SNA 
direct sessions. This can be set to zero (or very low) to prohibit 
(or restrict) intermediate node store-and-forwarding. 


Node resistance for this system 


Nodal resistance tolerance for alternate paths 


TPDEF Parameters: These should be examined when first implementing NJE 
or adding more nodes or workload. They control the general teleprocessing capa- 
bility of JES2 for NJE and RJE. 


SESSION 


BUFSIZE 


BUFNUM 


Maximum number of SNA sessions. (The default is the 
number of LINEnnnn UNIT=SNA< statements.) You need 
one for each NJE connection and one for each logical unit on 
SNA RJE workstations. If you have MLU remotes, you will 
have to specify more 


Maximum size of NJE transmission buffers for BSC, CTC and 
SNA. The default is 400 bytes which is not large enough for 
heavy NJE traffic. 


The actual transmission buffer size used is equal to the smaller 
value on the two adjacent nodes, and is determined at sign-on 
time. Presently in JES2/SP 2.1.5, good values for BUFSIZE 
are 1112, 1792 or 3840 bytes. See “JES2 TP Buffer Size and 
Virtual Storage Optimization” on page B-12. 


Number of teleprocessing buffers. Usually, the default (twice 
the number of lines defined) is sufficient. The BUFWARN 
parameter below may be used to tune the number of buffers. 
Also, use the $D TPDEF command to see how many buffers are 
unused. 
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BUFWARN TP buffer warning threshold. When the number of allocated 
TP buffers for NJE and RJE reach this percentage of available 
buffers, the operator is notified by the $HASP050 JES2 
RESOURCE SHORTAGE OF TPBF message. This param- 
eter may be changed with an operator command. 


Other JES2 Initialization Statements 


CONDEF MASMSG Maximum number of messages that will be queued on 


NETACCT 


JOBDEF RANGE 


APPL 


COMPACT 


DESTID 
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spool. If you use the shared spool connection as an inter- 
mediate node, this parameter should be increased. 


Network Account Number Conversion Tables: If you use 
the JES2 format of four-character account numbers and 
wish to translate the local numbers to a different set on 
other nodes or vice-verse, you may want to use this 
facility. An alternative is to use the 7% NETACCT control 
card in the job-stream, or a JES2 exit. 


Job number range for jobs originating on this node: It 
may be helpful to identify the origin of a job by its job 
number. ‘This parameter may be used to allocate job 
numbers only within this range to job onginating on this 
system. If you have a large number of jobs on this system 
or a large number of nodes in the network, you may not 
have enough latitude for each node to use this scheme. If 
a number in this range is not available, JES2 will pick a 
number outside the range. 


SNA application name and characteristics. This param- 
eter is only necessary if multiple systems (MAS members) 
on NJE nodes will be participating in SNA NJE sessions. 
A default value of the name on the LOGON] initializa- 
tion statement is generated for this node, and names on 
the NODEnnnn statements (if “SNA” is specified) are gen- 
erated automatically. 


SNA compaction table definition. Compaction 1s only 
supported with SNA transmissions and takes place after 
compression. It is only performed by JES2 although the 
other systems can de-compact data. Unlike RJE, com- 
paction is done on a session basis, not on an individual 
job or data set basis. 


Use this carefully; the overhead may not justify the data 
reduction. Only certain data can be effectively compacted 
for a given compaction table. See JES2 Initialization and 
Tuning for details. 


Route-code symbolic name. These are not usually 
required for NJE routing definitions, but may be helpful 
for changing a node’s name or an RJE remote number. 
They may also be used to provide more meaningful instal- 


READERnan 


Rnonnn.RDm 


lation names than those provided by JES2. Node names 
already defined by the NODEnnnn statements should not 
be defined on this statement. See the description in J/ES2 
Initialization and Tuning. 


Default print, punch and execution node for jobs sub- 
mitted through this local reader may be specified on the 
PRNODE, PUNODE, XEQNODE parameters, respec- 
tively. There are no equivalent parameters for internal 
readers. Because most installations use internal readers 
(e.g., TSO) for local job submission, these do not apply. 
(As an alternative use one of the reader exits.) 


Default print, punch and execution node for jobs sub- 
mitted through this remote reader may be specified on the 
PRNODE, PUNODE, XEQNODE parameters, respec- 
tively. 
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VTAM Parameters 


This section is not intended to replace the need for communication specialist 
involvement in the NJE implementation on a SNA network. The VITAM 
systems programmer is responsible for the VTAM definitions for NJE, but the 
following overview should help the JES2 systems programmer communicate the 
NJE requirements to that specialist. 


There are seven different members of VTAMLST to consider when setting up a 
NJE session on SNA: 


VTAM Start Options 

Network Configuration 
Cross-Domain Resource Definitions 
Cross-Domain Resource Managers 
Local VTAM Applications 

Path Definition Tables 

LOGMODE Table Entries 


These definitions must be specified and coordinated on each node using SNA in 
the network. The figure below shows conceptually how they fit together. 


ATCSTRxx — VTAM Start Options 


sub-area identification 
configuration pointer 


ATCCONxx — Network Configuration 


>|pointers to other lists 


xxCDRSC — Cross—Domain Resources 
>lother NJE applids “| 


xxCDRM — Cross—Domain Resource Mgrs 


»[itere they are Je 


PATHxx — Paths to Subareas 


>Ihow to get there 


APPLxx — Local VTAM Applications 
>lappl. attributes 


Logmode Table 


>|BIND Images 


See How JES2 Uses SNA for RJE and NJE GG22-9378 for more background on 
NJE implementation with SNA. 
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VTAM Start Options 


Network Configuration 


This member, named ATCSTRxx, defines various options for VTAM initializa- 
tion. For the purposes of showing how the parameters all fit together, only two 
are discussed here. Other parameters are discussed later under performance. 


HOSTSA Statement: ‘This defines the number of the host sub-area. Sub-area 
numbers are used in the cross-domain resource manager and path tables below. 


CONFIG Statement: In the following example, the two highlighted parameters 
are used to identify the local sub-area number and the suffix of the configuration 
member below. The remaining parameters are not addressed in this publication, 
but should be reviewed by a VTAM/communications specialist as part of the 
installation. 


HOSTSA=1, 
MAXSUBA=63, 
CONFIG=J2, 
CSALIMIT=0, 
ITLIM=0, 


SSCPID=1, 

MAXAPPL=150, 

VTAMEAS=150, 
IOBUF=(350,255,19,,50,50), 


This member, named ATCCONxx (where ’xx’ is defined in the VTAM start 
options member above), is merely a list of member names that are used to define 
cross-domain resources, cross-domain resource managers, paths and local applica- 
tions. 


Cross-Domain Resource Definitions 


This member is pointed to by the network configuration member, and contains 
CDRSC statements. It is used to define other nodes’ application-ids to VTAM, 
and identify which cross-domain resource manager controls them. The names 
should match the same APPLID name used by JES2 when issuing the $SN 
command in a SNA environment. 


The following example shows how to identify two NJE applications named 
NJENODE2 and NJENODE3 which belong to cross-domain resource managers 
defined later. The names of the resource managers are only used to match the 
names on the CDRM statements below and do not have to match names defined 
in other hosts. 


VBUILD TYPE=CDRSC 
NJENODE2 CDRSC CDRM=N2RMGR 


NJENODE3 CDRSC CDRM=N3RMGR 
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Cross-Domain Resource Managers 


This is also pointed to by the network configuration member, and contains 
CDRM statements. It is used to identify sub-area numbers with the names of the 
cross-domain resource managers referenced on the CDRSC statements above. 


The following example merely associates a sub-area number with the cross- 
domain resource manager and its resources defined above: 


VBUILD TYPE=CDRM 
N2RMGR CDRM SUBAREA=2,ISTATUS=INACTIVE 


N3RMGR CDRM SUBAREA=3, ISTATUS=INACTIVE 


Path Definition Tables 


Path definition tables are also pointed to by the network configuration member; 
this contains PATH statements which are used to tell VWTAM which adjacent 
sub-area is used to get to other sub-areas. 


The following two examples show how to direct VITAM to reach other sub-areas 
through the sub-area of the host-attached NCP (10): 


VBUILD TYPE=PATH 
PATH PATH DESTSA=(€2,3,20,30), 


ERO=(€10,1), 
VRO=0 


or alternatively, the same paths could be coded separately... 


VBUILD TYPE=PATH 
PATH2 PATH DESTSA=(€2,20),ER0=(€10,1),VRO0=0 


PATH3 PATH DESTSA=C€3,30),ERO=(10,1),VRO=0 


Local VTAM Applications 


This member is also pointed to by the network configuration member, and con- 
tains APPL statements. It is used to define this node to VTAM and other appli- 
cations (i.e., NJE subsystems on other nodes). It is also used to specify VTAM 
attnbutes of the applications and point to LOGMODE table entries below. 


The following example shows how to code the APPL statement, specifying PASS 
and ACQuire authonties, a pacing value of 4 and a LOGMODE table entry 
named NJEMODE in the member of VTAMLST named JESMODE: 


VBUILD TYPE=APPL 
NODEA APPL AUTH=CPASS,ACQ), 


VPACING=4, 
MODETAB=JESMODE, DLOGMOD=NJEMODE 
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LOGMODE Table Entries 


This member is pointed to by the APPL statements above, and contains 
MODEENT statements to specify BIND parameters for the SNA session. JES2 
creates the BIND from three sources: MODTAB, JES2 initialization parameters 
and an internal table. 


Example: 


JESMODE MODETAB 
MODEENT LOGMODE=NJEMODE, 
PSNDPAC=X'04', 
PRCVPAC=X'04', 


SSNDPAC=X'04', 
COS=X'00', 
ENCR=X‘'00' 


Session Establishment - BIND Creation 


In initiating a SNA session for NJE, both sides must first start WTAM and 
enable the VTAM ACB. (This is done in JES2 by $SLGN1, in BDT by X SNA, 
in RSCS by NETWORK START and in POWER by loading the NDT.) In addi- 
tion, JES2 must enable a logical SNA line with $SLNEnnn. Then either side 
may initiate the session. 


The general flow for initiating any NJE SNA session may be shown as follows: 


Start VTAM 
Open ACB 


Start VTAM 
Open ACB 
Start Session 
OPNDST (ACQ) 


or SIMLOGON ———————- CD INIT 
(see Note 1) 


< CDINIT RSP (COS Name ) 


<— CDCINIT (BIND Image) 


<Received Bind 


Maybe Changed> |——————— BIND. —————————__ SCIP Exit 
<If Bind is 
Acceptable> 
OPNDST Exit <————— +RSP —_—_—_———_ OPNSEC 


Primary LU Secondary LU 


Note: 
JES2 and POWER use OPNDST (ACQ); BDT and RSCS use SIMLOGON.® 


The side which successfully initiates the session becomes the primary logical unit 
(PLU) for the life of the session and the other is the secondary logical unit 


6 For JES2 details see the section on “Session Establishment” in How JES2 uses SNA 
for RJE and NJE, GG22-9378. 
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(SLU). After receiving a BIND image from the SLU, the PLU sends the final 
(non-negotiable) BIND image to the SLU. This becomes relevant in determining 
various parameters such as pacing values and class-of-service (COS). 


The first side which successfully issues the $SN,A=applid command becomes 
the pnmary LU. 
JES2 JES2 


$S_ LGN1 
$S LNEn 


$S_ LGN1 
$S_LNEn 
$s N,A=. ee 


OPNDST (ACQ) |———— CDINIT ————————————_> 
CDINIT RSO (COS Name) —— 
CDCINIT (BIND Image) —— 


<Received Bind 
Not Changed> |——————— BIND ——————————_>|_ SCIP Exit 
<Verify Bind> 
OPNDST Exit —————_—_ ¢RSP—-————— OPNSEC 


Primary LU Secondary LU 


The only parameter in the LOGMODE table entry that is used for NJE is the 
SSNDPAC (secondary send pacing). 


The BIND image sent by the SLU in response to the CDINIT are used for the 
session without change by the PLU. The RU size is determined by the 
BUFSIZE parameter on the TPDEF initialization statement; the smaller of the 
two connecting systems 1s used. 


SNA Performance Considerations 
Pacing: Observe the following points in setting up pacing parameters: 


e Never use zero (0) pacing with NJE. Zero means no pacing which can allow 
either NJE application overrun the other. This may create slowdown prob- 
lems, excessive buffer utilization in VITAM and degrade other SNA sessions. 


e Pacing values should be at least as high as the number of lines in the trans- 
mission group. Otherwise, any lines greater than the pacing size go essen- 
tially unused. 


e Ensure that the pacing parameters you have specified are the ones actually in 
use on the session. with NETVIEW or VTAM traces. 


For the primary LU, the VPACING value and a non-zero SSNDPAC value 
from the secondary’s logmode entry allows the primary to specify his inbound 
pacing rate. For the secondary LU, VPACING on his APPL statement specifies 
his inbound pacing rate. In NJE, the node at which the ‘$SN,A=nodeid’ 1s 
issued becomes the primary LU. NJE installations should specify VPACING=n 
on VTAM APPL statements and also specify a MODETAB and DLOGMOD 
which contains a non-zero SSNDPAC value. Both VPACING and SSNDPAC 
values should be identical, at least for initial testing. Failure to specify pacing can 
cause the line to become flooded with NJE data. This may cause NCP to go into 
slowdown mode or a fast CPU to overload a much slower one. 


See ‘“NJE Session Initialization” on page B-18 for more discussion on pacing. 


RU (Teleprocessing Buffer) Size: In JES2, the NJE RU size is determined by 
the BUFSIZE parameter on the TPDEF initialization statement. It is set in 
three fields during NJE session establishment: in the BIND, the FMH type 4 and 
the initial and response signon records. However, JES2 only checks the RU size 
when receiving the FMH type 4. If the received size from the other node 1s dif- 
ferent from this node’s buffer size, the smaller of the two RU sizes is used. 


The actual buffers in JES2 memory are prefixed with an RPL or IOB so they are 
(BUFSIZE + 252) bytes long and will not span a 4K page boundary. Therefore, 
good values for BUFSIZE with JES2/2.1.5 are 1112, 1792 or 3840 bytes. See 
“JES2 TP Buffer Size and Virtual Storage Optimization” on page B-12. 


RPL Count: JES2 currently sets the number of inbound RPLs to 6 and the 
number of outbound RPLs to 3. (See the EQUates SINLIM and SOUTLIM in 
HASPSNA). 


Multiple Transmitters and Receivers: Currently, multiple transmitters on a single 
session (or BSC line) are not serviced equally. Therefore, the performance bene- 


fits of defining multiple transmitters are not fully realized, especially with larger 
transmission buffers.’ 


7 See APAR OY06446. 
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Compaction 


Multiple Sessions between JES2 Nodes: See “Second Session Between Two 
JES2 Systems” on page B-2. 


There are many parameters in VTAM and NCP that can affect NJE perform- 
ance, as well as many environmental variables. Consult with your communi- 
cations specialist and VWTAM/NCP systems programmer, and see “Performance 
Management” on page 2-44 for more discussion. 


JES2 always sets the compaction indicator on even if compaction is not being 
used for that session. This is because JES2 is always able to receive a compaction 
table even though it may not send one. 


JES2 only sends FMH3 if compaction for the receiving node is indicated during 
JES2 initialization (via APPL or Nnn statements) and the receiving node has 
indicated compaction is accepted via the flag bit in FMH4. 


Compaction is only supported with SNA transmissions and takes place after 
compression. It is only performed by JES2 although the other systems can de- 
compact data. Unlike RJE, compaction is done on a session basis, not on an 
individual job or data set basis. 


Use this very carefully; the overhead may not be worth it and only certain data 
can be effectively compacted for a given compaction table. 


Miulti- Access Spool Considerations 
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JES2 multi-access spool (MAS) nodes may either have all NJE connections on 
one member, or they may be spread over the complex. 


It is generally easier to have identical JES2 initialization parameters on all JES2 
members in the complex, even if there are no plans to have NJE connections on 
certain systems. (You may want to switch the NJE lines over to another 
member if the NJE system 1s unavailable.) 


If a member has no NJE connections and will not be used for back-up, then all 
parameters except OWNNODE may be omitted on the NJEDEF statement. 
Also, unless required for RJE, the TPDEF LINE and LOGON initialization 
statements may all be omitted. The OWNNODE parameter on the NJEDEF 
statement and the NODE statements must all be specified (the same) on all 
members. 


CONNECT statements must specify the correct system ID number (1-7) on the 
MEMBA and MEMBB parameters. This is a common source of problems in 
failing to make an NJE connection. See also “Backing-Up Predefined 
Connections” on page 2-11. 


See also the section on “Multi-Access Spool Considerations” in the chapter on 
“Network Job Entry” in JES2 [nitialization and Tuning. 


Testing Techniques 


Secondary JES2 Subsystems: Entire JES2 networks can be simulated on a single 
MVS system by running a secondary copy of JES2 for each node you want to 
simulate. Even multi-access spool nodes can be simulated by having a secondary 
JES2 for each member. The nodes can then be connected by intra-domain SNA 
sessions without requiring any real transmission lines. Alternatively, BSC lines 
can be wrapped between two ports on the same controller, or 3088 connections. 


VM/370 Virtual Machines: VM/370 can give you even more flexibility by simu- 
lating JES2 and non-JES2 nodes. The connections can then be made via virtual 
CTC adapters which again require no real transmission facilities. 


Installation Exits and Modifications 


JES2 Exits 


Job Routing and Screening: ‘There are no exits specifically for NJE, but the exits 
in JES2 input processing can be used to screen jobs coming into a JES2 node for 
execution. 


Reader Exits (2, 3, 4, 20): These exits are taken at both the submitting and 
execution JES2 nodes. 


These exits can be used to change the execution node for the job by setting the 
JCTXEQND field in the JES2 Job Control Table (JCT). They can also change 
the default print or punch route code for the job by setting the JCTPROUT 
and/or JCTPUOUT fields in the JCT. 


Any JOB statement changes made by exits 2 or 3 at the submitting node will be 
transmitted to the execution node if a “¥XEQ statement is used. JCL/JECL 
images added, changed or deleted by exit 4 at the submitting node will be trans- 
mitted to the execution node. Exits 2, 3, and 4 (and JES2 input processing) do 
not see any JCL or JECL statement after the “*%XMIT statement on the submit- 
ting node. 


Notification Exit: Exit 13 is invoked from the SYSOUT transmitter when the 
data set header has been read and processed for a file sent by the TSO/E Interac- 
tive Data Transmission Facility. It is only invoked when the destination user-id 
matches the external wnter name (non-blank). The exit can be used to screen 
incoming files or to notify the recipient that an incoming file has arrived. 


JCT Extensions: JCT user fields (JCTUSERn) and any user-defined fields in the 
JCT, are not transmitted with the job unless they were moved by the installation 
into the job header. See “Adding User Sections to NJE Headers (JES2)” on 
page B-22 for details on adding user sections to network headers. 
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RSCS Exits 


POWER Exits 
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There are several installation exits in JES3 networking code. Some of the exits 
allow the installation to modify fields in the job or data set headers for received 
data, and some allow modification of the headers before transmit. A bnief 
description of each of the user exits follows. 


e IATUX35 - validate or authorize commands from other nodes which execute 
locally. 


e TATUX36 - pull accounting information from the first segment of the job 
header for received jobs and SYSOUT. 


e IATUX37 - modify the first segment of the data set header for received 
SYSOUT data sets. 


e [ATUX38 - perform special processing of SYSOUT class for received data 
sets with this exit. 


e [ATUX39 - modify the data set header constructed by this node for the 
SYSOUT from locally executed jobs. 


e JATUX40 - modify the job header built for locally submitted jobs. 
e IATUX42 - notify recipients when Netdata files arrive. 


e IATUX43 - modify the job header for SYSOUT data sets from locally exe- 
cuted jobs which are to be transmitted. 


RSCS may be customized via installation exits to do the following: 


Reject or change the priority of a file when queued for transmission 

Tailor accounting information on file transmissions, receipts or when purged 
Tailor transmission algonthms 

Examine and modify NJE headers and trailers (RSCS Version 2.2 only) 


For details, See RSCS Networking Exit Customization, LY24-5240 (or RSCS 
Networking Planning and Installation, SH24-5057 for RSCS Version 2.1). 


PNET Reader Exit: The RDREXIT may be used to examine NJE headers for 
both SYSIN and SYSOUT jobs as well as the JCL or JECL in jobstreams as 
they are read into the POWER system. 


See the VSE/POWER Networking User's Guide, SC33-6140 and VSE/POWER 
Installation and Operations Guide , SH12-5329 for more information. 


Network Management 


Availability and Recovery 


Link Failure 


Host Outage 


Alternate Mechanisms 


Parallel Links: Parallel BSC or CTC connections, multiple SDLC lines in a 
transmission group and parallel SNA sessions between two NJE systems provide 
good redundancy especially if separate communications facilities are used. 


Alternate Paths: Even if there is no direct link available to a node, many NJE 
networks are so interconnected that there are other routes available. 


This may require changing CONNECT statements or the RESTMAX parameter 
before JES2 will allow the routing over an alternate path. 


Back-Up Communication Facilities: Even if parallel links or alternate paths are 
not available, there should be spare lines, modems and communication control- 
lers that could be switched in if the critical facilities cannot be repaired imme- 
diately. Dial-up lines may be used in an emergency, but their slow speed may 
not be sufficient for productive volumes. 


If there are other JES2 members in the complex, the NJE lines may be switched 
to one of those, assuming there are no pre-defined connections to adjacent nodes. 


If there are pre-defined connections and other processors available but running 
other work, then the JES2 on the failing system may be brought up as a sec- 
ondary subsystem on a live system. Likewise, if there is a test system or VM 
system available, the logical JES2 system may be brought up there. (If the con- 
nections are SNA, this technique would require a significant amount of additional 
VTAM parameters to be changed or replicated.) 


If the host is an intermediate node, then find a way around the down host. See 
the section on Link Failures above. 


If the host is the destination node and the outage appears to be long, jobs could 
be routed to alternate nodes if the execution or printing resources are available a 
those locations. See “Execution Node Requirements” on page 4-16 and “Output 
Node Requirements” on page 4-28. 


Spool Offload: JES2 uses NJE protocols for spool offload operations. There- 
fore, jobs destined for a node which is unreachable could be offloaded on one 
system and the offload data set (tape) carried to the destination JES2 systems. 
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Careful planning should reduce the frequency of parameter changes that may 
require disruptions to the network and to individual systems. 


Network Restart: Almost all NJE changes can be made on individual nodes 
without requiring simultaneous changes on all nodes in the network. Exceptions 
to this in JES2 include errors in the Nodes Attached Table (NAT) where one 
node IPLs with a future TOD clock setting. The path manager will not honor a 
connection until that tume is reached, or until the entire JES2 NJE network is 
shut down simultaneously.2 To avoid this and other problems such as SMF 
accounting and data set expiration dates, make certain that the system is always 
IPL-ed with the correct time and date. 


Practically all APAR fixes are coded so that they can be installed node-by-node 
in any order without requiring a network-wide warmstart.? User modifications to 
JES2 should also provide for staged implementation in a NJE network. 


System Cold-Start Avoidance: Cold-starting a JES2 system can be painful, espe- 
cially if it is a multi-access spool (MAS) complex with several processors. The 
only NJE parameter which requires a cold-start to change 1s: 


¢ OWNNODE parameter on the NJEDEF statement 


Changing Node Numbers or Names: NJE node numbers and node names should 
only be changed when there is no work on the queues for those nodes. Spool 
offload should be used to preserve the nodal routing of jobs if you need to 
change the node a node’s number or name. Even though most of the routing 
information for jobs and output is expressed in spooled control blocks in terms 
of node number, there are some that reference nodes by name. 


In addition, there are also other cold-start parameters which may need to be 
changed because of the increased workload imposed by NJE: 


¢ SPOOLNUM and TGNUM parameters on the SPOOLDEF statement 
¢ JOQENUM parameter on the OUTDEF statement 
e JOBNUM parameter on the JOBDEF statement 


The NODENUM parameter on NJEDEF can only be decreased on a cold-start. 
(It can be increased on an 


Also, CONNECT statements should be synchronized across all members of a 
MAS complex, so they should be changed only with an all-systems warm-start. 


8 See APAR 0762754. 


? APAR 0253846 for JES2, and VM13405 for RSCS are the only known exceptions. 


Spool Offloading NJE Jobs: Because spool offload stores jobs in NJE format, 
the node names (not numbers) are preserved. With the enhanced spool offload 
facility in JES2 1.3.6/2.1.5, the node name can be used as a selection criteria or 
modified to a new name or number upon reload. This 1s especially handy when 
changing OWNNODE. 


Nodal message records (commands or messages) are not offloaded. 


Initial Implementation of NJE: \f no NJE parameters are defined in JES2, the 
local node-name defaults to ‘NI’, the number of nodes defaults to 1 and 
OWNNODE defaults to 1. The local node name and number of nodes may be 
changed with just a JES2 warmstart, butt OWNNODE can only be changed with 
a JES2 cold-start. 


If joining a large JES2 NJE network, you should keep the node numbers con- 
sistent to minimize confusion amongst operators and specify the same node 
number used by the other JES2 nodes. (They do not have to be the same 
because NJE protocols between nodes always use node names.) If this is not 
feasible, you may keep OWNNODE the same to avoid a cold-start temporarily, 
but they should be made consistent at the next opportunity. 


Chapter 2. Systems Programmer’s View of NJE 2-43 


Performance Management 


Throughput Optimization 


NJE performance can be measured by job throughput and/or job transit time. 
To those managing the system and network resources, throughput may be the 
most important measurement of performance. To the end user and production 
scheduler, however, performance should be measured in job turn-around or 
transit time. 


Throughput is a function of line utilization, buffer sizes, pacing parameters, sub- 
system dispatching priority, hardware resources, other contending work for the 
same resources and many other factors. Job throughput can be measured in 
terms of jobs, records, or bytes transferred per unit time. 


See “Second Session Between Two JES2 Systems” on page B-2 for two 
approaches to improve throughput. 


Job Turnaround or Transit Time 


High priority work requiring NJE transmission may be more important than 
over-all throughput. If so, several factors may help: 


e Higher speed lines will minimize transmission time. For a single job trans- 
mission, one high-speed line (or transmission group) is faster than a large 
number of lower-speed lines. 


e Increased throughput capacity may minimize transmission queue delays. 


e If the important work volume is high, breaking it up into separate jobs or 
spin-off output elements will allow parallel or overlapped transmission and 
processing. 


e Eliminate intermediate node store-and-forwarding. 


e Set up multiple transmitters with different classes of service or selection algo- 
rithms to allow high pnonty jobs to be transmitted on reserved streams. 
(This requires a modification to JES2.) 


Once a job 1s selected by a transmitter, it will not be preempted by another. 
Therefore, it is important not to let a long job tie up a transmitter for 
extended periods when there is more important work to be sent. 


Symptoms of Performance Problems 
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Performance should be monitored by the a performance management group, but 
problems are usually first noticed by the systems operators or even end-users. 
See “Network Problem Determination” on page 3-13 for a discussion on the fol- 
lowing points: 


e No Work Being Transmitted 
e Transmission Queues Growing 
e High CPU Utilization 


Performance Measurement 


e High Pnority Work Not Being Selected 
e ’Ping-Ponging” Files 
e Response Time Degradation on other Applications Sharing the Line 


Data should be collected continuously to monitor NJE performance. SMF 
records may be analyzed to measure both throughput and turnaround. 


Job Turn-around: Transmission, execution, printing and queueing at each phase 
contnbute to the over-all job turn-around time. 


Job 
Submit 
1 
<—Queue> 3 <repeat for each> 
Time <—Xm1 t-—> 4G intermediate S&F 
Time |<—Queue> node 
Time <—Exec—> 6 
<repeat for each> Time <—Queue> 
intermediate S&F Time |<—Xmit-—> 8 
node Time <—Queue> 9 
Time <Print> 
Time 


Figure 2-7. Elements of NJE Job Turnaround Time 


SMF type 6, 26 and 57 records can be analyzed to show most of these events and 
queue times. 


l. 


Time/date on reader at ongin node - SMF26RST/SMF26RSD - recorded at 
every node and carried in the job header field NJHGETS. (Also recorded in 
type 6 records, but not type 57.) 


Job transmitter start tume/date - SMF26NST/SMEF26NSD - recorded on job 
transmitter nodes only. 


Job transmitter stop time/date - SMF26NPT/SMF26NPD - recorded on job 
transmitter nodes only. 


Execution start tume/date - SMF26XST/SMF26XSD - recorded on execution 
(and SYSOUT transmitter) node(s) and carried in the job trailer field 
NJTGSTRT. 


Execution stop time/date - SMF26XPT/SMF26XPD - recorded on execution 
(and SYSOUT transmitter) node(s) and carried in the job trailer field 
NJTGSTOP. 


SYSOUT transmitter start tume/date - SMF57TSS/SMEF57DSS - recorded on 
SYSOUT transmission nodes only. 


SYSOUT transmitter stop time/date - SMF57TPS/SMF57DPS - recorded on 
SYSOUT transmission nodes _ only. Output processing _ start 
(SMF26OST/SMF26OSD) 1s close to the transmitter stop because output 
processing usually happens very soon after the output arrives at the pnint 
node. 
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8. Pmnt/Punch start time/date - SMF6WST/SMF6WSD - recorded on the print 
nodes only. 


9. Pmnt/Punch stop time/date is not recorded. The time/date the type 6 record 
is written (SMF6TME/SMF6DTE) but may be significantly later than end of 
print if it hung on the back of the 3800E. 


There are also other time stamps in the SMF type 26 records that may be useful 
in tracking jobs. 


Adjusting for time-zone offsets, the SMF records can be accumulated at a central 
site and analyzed. 


Throughput Measurements: Transmitter, line or session utilization can be 
approximated by analyzing SMF records (48, 53, 26 or 57) or the SYSLOG data 
sets. 


JES2 Tuning Parameters: There are many parameters and variables in JES2 that 
can affect NJE performance including, but not limited to: 


Size and Number of TP Buffers 

Size and Number of Spool Buffers 

Spool and Checkpoint Data Set Response Time 

JES2 Dispatching Pnority 

Number of Transmitters and Receivers per NJE Line 

Compaction 

JES2 Storage Usage 

Size of JES2 Job and Output Queue, and Number of Active Elements 


See JES2 Initialization and Tuning, and JES2 Performance Considerations, 
GG66-0205. 


VTAM Tuning Parameters: There are many parameters in VTAM and NCP, as 
well as other environmental variables that, can affect NJE performance. 


VPACING 

Pacing at the transmission, path and data link control levels 
Transmission Pnonty, Class of Service (COS) 
NCP MAXOUT 

Number and Size of VTAM Buffers 

Line Speed 

Transmission Groups 

Line Utilization 

Use of Satellites 

Delay Compensators 

Other Interactive Traffic on the Link 

NCP Utilization 

VTAM Storage Usage 


Many of the above parameters and variables above affect one another in complex 
ways. See “SNA Performance Considerations” on page 2-37 and consult your 
communications specialist for advice before changing any of these parameters. 


Accounting Considerations 


Collecting Accounting Data 


Accuracy of Time Stamps 


SMF Records 


Collect useful data in order to manage the network, track jobs, audit for unau- 
thorized use, and for billing. 


Normally, accounting information is recorded at each host. To account for total 
network usage, these local data files must be merged and processed at a central 
point. 


Network design can help facilitate this data collection and reporting. For 
example, the star network in Figure 2-1 on page 2-4 has simpler traffic patterns 
and the accounting files could all be sent to the “hub” of the network where 
many of the records are collected anyway. A full mesh configuration has more 
complicated traffic patterns, but could still be managed if the accounting records 
were sent to a common node. 


When combining records from multiple nodes, they have to be identified as to 
their node of origin which is not recorded in the records themselves. This 
requires some non-trivial installation programming. 


Uniquely Identifying Jobs: The following criteria may be used to uniquely iden- 
tify a job, but are not available in all accounting records. Therefore, a subset of 
these “identifiers” may be sufficient. 


Ongin Node Name 

Ongin Job Identifier 

Job Name 

Time on Reader at Ongin Node 


PWN > 


The TOD Clock must always be set with the correct offset from Greenwich 
Mean Time (GMT). Failure to do so in an NJE network spanning multiple tume 
zones will create incompatible tume stamps in SMF records, and Network Con- 
nection records (used by the path manager). 


SMF (System Management Facilities) is a function of MVS that allows the col- 
lection and recording of various types of system and job-related information. This 
information 1s recorded in the form of a number of different records, which are 
numbered. Installations can process the SMF records with any number of appli- 
cation programs to analyze the data, produce reports, etc. 
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Job Header and Trailer Fields: Most of the information recorded in SMF 
records is transmitted in the NJE job header as the job is routed from node to 
node. The job trailer designed to carry job statistics that may not be available 
until the job is practically at the end of transmission. 


See System Management Facilities GC28-1030 (370) or GC28-1153 (XA) for 
detailed description of the SMF records. 


JES2 uses SMF Type 26 (job purge) records to record all successful SYSIN job 
transmissions, and SMF Type 57 records to record all successful SYSOUT trans- 
missions. Since multiple SYSOUT data sets may be transmitted within a job 
header and trailer, this record may represent multiple SYSOUT data sets. 


None of these records record the node name of the local node. This can be a 
problem when combining records from multiple sites. 


Type 26 Records: Execution node name (and other execution-related fields) are 
not recorded in the type 26 record when the jobs executes on the origin node. 


Type 57 Records: ‘The following standard job-header information is missing 
from the type 57 record cut by JES2: 


e Jobname 
e Time and Date on reader at original node 
e User Identification from common exit parameter area 


NJE Network Management Records: JES2 records the following information 
reflecting network events. 


e 55 Network Sign-on 
e 56 Network Integrity (invalid password) 
e 658 Network Sign-off 


Other Records: The following information is missing from the type 6 record cut 
by JES2 and other records (e.g., type 4 2d 5) 


e Onginal Job Number 
e Onginal Node Name 


Network Account Number: The Network Account Number is an &-character 
identification that can be used in NJE environments. It can be useful in coordi- 
nating multiple installations with overlapping 4-digit local account numbers. 


JES2 uses the Network Account Number in the job header if specified by the 
user on the /*NETACCT JECL statement, or converted from a local account 
number to a network account number through local-to-network account table set 
up by the NETACCT JES2 initialization statements. Otherwise, it defaults to 
the local account number, but on the origin node only." 


10 Fixed with APAR 0260994. 


JES3 Accounting Records 


Two SMF records are recorded by JES3 which contain network-related informa- 
tion. These are SMF type 26 and SMF type 57 records. The type 26 record 1s 
produced when the job is purged from the system and contains various job 
summary information. The type 57 record is produced for each transmitted job 
(or SYSOUT) after successful transmission and contains summary and resource 
usage information related to the network processing of the job. 


There are no records produced in JES3 which record information of a network 
management nature. 


Network Account Number: Users submitting jobs from JES3 can specify certain 
accounting information which they wish to accompany their job. This is accom- 
plished by using the //*NETACCT control statement in the job’s JCL stream. 
Refer to Figure 4-4 on page 4-12 for information on the placement of this state- 
ment in the JCL stream. The information which can be supplied on this state- 
ment is as follows: 


PNAME programmer’s name (1-20 characters) 


ACCT network account number (1-8 characters) 
USERID userid for ongin or notify (1-8 characters) 
DEPT user’s department (1-8 characters) 

BLDG user’s building (1-8 characters) 

ROOM user’s location (1-8 characters) 


This information is placed in the NJE job header which is built for the job. 
MVS/BDT Accounting Records 

MVS/Bulk Data Transfer writes a type 59 record when a file-to-file transmission 

is completed and when an NJE transmission is completed. In the case of an NJE 


transmission, a special transaction type section is included for NJE. 


See System Management Facilities GC28-1030 (370) or GC28-1153 (XA) for 
detailed description of the type 59 SMF record. 


RSCS Accounting Records 
If the ACCT (account) option is on, RSCS creates an accounting record for file 
transmissions and receipts. These can be customized by installation exits. See 
RSCS Networking Planning and Installation, SH24-5057 and RSCS Networking 
Exit Customization, LY 24-5240 for details. 

POWER Accounting Records 


The following account records are written by POWER and are mapped by the 
PACCNT macro 


Network Record: Written for each SNA networking session or BSC networking 
connection. 


Transmit/Receive Record: Written for each job or SYSOUT transmission or 
reception via NJE. 
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Other Account Records: POWER may also wnite account records for execution, 
list, punch, RJE and other activities. See Chapter 5 of VSE/POWER Installation 
and Operations Guide, SH12-5329. 


Accounting Summary 


The following table summarizes the information recorded by each of the systems 
to account for NJE network usage. It does not show all the NJE accounting 
information recorded by each system, but shows where most of the common 
information is recorded. ‘There may be differences in the values and circum- 
stances for many of the fields. Consult the product documentation referenced 
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above for detailed information. 


NJE MVS MVS VM VSE 

Activity JES2 JES3 RSCS POWER 

Job Transmission SMF26-Jobs SMF26-Jobs Network Transmit/Receive 

(including SMF57-SYSOUT SMF57-OUT/BSC Accounting Account Record 

SYSOUT) SMF59-OUT/SNA _ Record 

Job Receipt - N/R - - N/R - Network Transmit/Receive 

(including Accounting Account Record 

SYSOUT) Record 

Sign-On’s SMF55 -N/R- - N/R - -N/R- 

Sign-Off’s SMF58 -N;R- - N/R - Network 

Account Record 

Start Line SM F47-BSC -N/R- -Nj/R- -N/R- 
SMF52-SNA 

Stop Line SMF48-BSC - N/R - - N/R - -N/R- 
SMF53-SNA 

Integrity SMF49-line -N/R- - N/R - - N/R - 
SMFS56-net 

Figure 2-8. Accounting Records for NJE Activities 


-N/R- Not Recorded 


(*) Generated internally 

C8 Character field with a length of 8 bytes 

B2 Binary field with a length of 2 bytes 

P4 Packed decimal field with a length of 4 bytes 

Note 2 Destination Node and Userid for VM does not distinguish between execution, print or punch. 


Prefixes for NJE Headers and Accounting Records 


NJHG.. Network Job Header General Section 

NDHG.. Network Data Set Header General Section 

ACNT.. VM/RSCS Network Accounting Card 

SME26.. JES2 and JES3 SMF Job Purge Record 

SMF57.. JES2 SMF Sysout Transmitter Record 

SMF59.. MVS/BDT Transmission Record 

SMENJ.. JES3 SMF Sysout Transmitter Record 

NJE.. JES3 Job Networking Extension to the SMF 26 Record 
AC.. POWER Account Record Header 

NET.. POWER Network Account Record 

NAC.. POWER Transmitter/Receiver Account Record 

@@ = 'RDR’, ‘EX’, ‘LST’, or ‘PUN’ (POWER Account Record) 


SMF59NDT C4 


Time on Reader at Original SMF26RST P4 SMF26RST P4 - N/R - 
Node (NJHGETS) SMF57 - N/R - SMF57 - N/R - 
SMFSIONDT +4 C4 


Accounting Information MVS MVS VM VSE 

(NJE header field) JES2 JES3 RSCS POWER 

Date Recorded (local time) SMFHDDTE P4 SMFHDDTE P4 ACNTDATE C6 ACDATE C8 
(00Y YDDDF) (00Y YDDDF) (MMDDYY) (MM/DD/YY) 

Time Recorded (local time) SMFHDTME B4 SMFHDTME B4 ACNTDATE+ 6 C6 ACSTOP P4 
(100ths of secs) (100ths of secs) (HHMMSS) (OhhmmssF) 

Local Node C8 (*) - N/R - - N/R - - N/R - NACCURR 

@@NODE 

Local System ID (*) SMF26SID SMF26SID ACNTSYS C5 ACSYSID CLI 
SMF57SID C4 SMFSYSID C4 (serial & model) 

Job Name C8 SMF26JBN SMF57 SMF26JBN -N/R- ACNAME 

(NJHGJNAM) -N/R- SMFS59NAM 

Local Job ID (*) SMF26JID C8 SMF26JNM C4 ACNTID B2 ACNUMB B2 
SMF26JNM C4 SMFNJNUM C4 
SMF57CJD C8 SMFS59JID C8 

Original Job or file ID SMF26NJB C8 NJEJOBNO B2 ACNTOID B2 NACORGJ# B2 

(NJHGJID) SMF57JID C8 SMFNJONM B2 @@OJ# B2 

SMFS59NUM B2 
Date on Reader at Original SMF26RSD B4 SMF26RSD B4 -N/R- - N/R - 
Node (NJHGETS) SMF57 - N/R - SMF57 - N/R - 


Origin Node C8 SMF26NON SMF26IGP ACNTILOC NACON 
(NJHGORGN) SMFS7ONN SMFNJORG @@FRNO 


Origin Remote ID SMF26INR+2 B2 SMF26 - N/R - ACNTUSER C8 @@FRM B1 ' 

(NJHGOGR) SMF57 - N/R - SMFNJRMT C8 

Origin Userid C8 -N/R- NJEUSRID ACNTUSER NACOUS 

(NJHGUSID) SMFNJUSR @@FRUS 

Origin System ID - N/R - -N/R- -N/R- - N/R - 

(NJHGORGQ) 

Execution Nodename C8 SMF26NXN NJEXEQU ACNTDEST NACTN (if SYSIN) 

(NJHGXEQN) SMFS7ENN SMFXEQM (note 2) EXXNODE 
SMF59XQN 

Execution Userid C8 -N/R- NJEUSID ACNTTOVM NACTUS (if 

(NJHGXEQU) NJEXEQU (note 2) SYSIN) 
SMF59XQU 


Figure 2-9 (Part 1 of 2). Accounting Information Recorded at each System 
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Accounting Information MVS MVS VM VSE 
(NJE header field) JES2 JES3 RSCS POWER 
Execution System ID (*) MF26XID C4 SMF26XID C4 ACSYSID Cl 


S a 
Print Destination Node SMF26PRD B2 -N/R- ACNTDEST C8 NACTN LSTNODE 
(NJHGPRTN) SMF57 - N/R - (note 2) 

S! 


Print Dest’n Userid MF26PRD + 2 B2 - N/R - ACNTTOVM C8 NACTUS 
(NJHGPRTR) SMF57-N/R- (note 2) LSTTOUS 
Punch Destination Node SMF26PUD B2 - N/R - ACNTDEST C8 NACTN 
(NJHGPUNN) SMF57 - N/R- (note 2) PUNNODE 
Punch Userid SMF26PUD+2 B2 - N/R - ACNTTOVM C8 NACTUS C8 
(NJHGPUNR) SMF57 - N/R- (note 2) PUNTOUS 
Next Node C8 SMF26NNM SMFNJPTH - N/R - NACADJ 
SMFS7NNM 


Network Account Number SMF26NAC NJEACCT 
C8 (NJHGACCT) SMF57ACN SMENJACT 
SMF59NAN 


File Size - # Records SMF26ICD B4 SMFNJRCT B4 ACNTRECS C4 NACCNTD B4 
(NJTGALIN, -ACRD, *) SMF57CNT B4 
File Size - # pages (APA) SMF26XPG B4 SMF26XPG B4 -NjR- -NjR- 
(*) SMF57 - N/R - SMF57 - N/R - 
File Size - # TP buffers (*) | - N/R- SMF26 - N/R- -NiR - -N/R - 
SMFNJTRN B4 


File Size - # Bytes - N/R - SMF26XBT B4 ° -N/R- - N/R - 
CMRNJCNT B4 
(after compression) 
i R- 


Department (NJHGDEPT) | -N/R- NJEDEPT C8 -N/R- -NjR- 

SMFNJDPT C8 

SMF59NP# C8 
Building (NJHGBLDG) -NjR- NJEBLDG C8 -N/R- -N, 

SMFNJBLD C8 

| SMFS59NPB C8 

Location (Room) SMF26ROM C4 NJEROOM C8 - N/R - - NjR - 
(NJHGROOM) SMFNJLOC C8 

SMFS59NPR C8 
Programmer Name SMF26NAM C20 SMF26NAM 


(NJHGPRGN) SMF57 - N/R - SMFNJPGM C20 
SMFSINPN C20 
In addition to the above, there are other accounting records for job input, exe- 
cution and output. There are also many other fields that are recorded by the 
various systems. Consult the product d~-umentation for details. 


Figure 2-9 (Part 2 of 2). Accounting Information Recorded at each System 
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This chapter addresses the operational considerations of NJE. It is not written 
directly for the general operator, but more for the operations supervisor or 
systems programmer responsible for developing guidelines for the operations staff. 
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Prerequisite Publications 


JES2 


JES3 


VM and RSCS 


POWER 
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JES2 NJE 


The following publications are the minimum required set for operators of NJE 
systems. Where multiple form numbers are referenced, ensure that you have the 
appropniate one for your installation. See Appendix C, “Bibliography” for a 
complete list of NJE publications. 


MVS/JES2 Systems Operators are also the NJE Operators. 


e JES2 Commands, SC23-0048 (Ver. 1) or SC23-0064 (Ver.2) 
e JES2 Command Syntax, SX23-0008 (Ver. 1) or SX23-0010 (Ver.2) 
e JES2 Messages, GC28-1354 (Ver. 1) or GC28-1353 (Ver.2) 


As with JES2, the MVS System operator can also be the “NJE operator”. 


e JES3 Commands, SC23-0045 (Ver. 1) or SC23-0063 (Ver. 2) 
e JES3 Command Syntax, SX23-0007 (Ver. 1) or SC23-0012 (Ver. 2) 
e JES3 Messages, GC23-0044 (Ver. 1) or GC23-0062 (Ver. 2) 


MVS/BDT (Ver.2): If SNA NJE 1s used with JES3, then BDT 1s also required: 


BDT Commands, SC23-0226 

BDT Messages and Codes, SC23-0227 

BDT Command Reference Summary, SC23-0228 

JES3 SNA NJE Installation Considerations, GG66-0253 


The RSCS “operator” is actually a special class of VM user who starts up the 
RSCS virtual machine. After starting up the network, the RSCS virtual machine 
usually runs unattended and disconnected. 


e VM/SP Operator's Guide, SC19-6202 
e RSCS Networking Operation and Use, SH24-5058 
e RSCS Reference Summary, SX24-5135 


VSE/POWER Installation and Operations Guide, SH12-5329 
VSE/POWER Networking User's Guide, SC33-6140 
POWER Reference Summary, SH12-5435 

POWER Networking Design Guide, GG24-1570 


Network Control 


Network Start-Up 


JES2-JES2 Connections 


In general, the steps for starting a JES2-to-JES2 NJE connection are simple: 


Start JES2 on both systems. 

Enable the Communication Facilities and Access Methods at both sites. 
Start the Lines at both nodes. 

Start Networking on one of the lines. 


&wWN 


Dial-up connections are supported for both BSC and SNA, but the connections 
must be established manually. 


BSC Connections: After JES2 is started (S JES2 and $S), the logical JES2 tele- 
processing lines must be started on each side of the connection. After both sides 
have started the lines, the $SN command can be issued on either node to start the 
NJE session. Jobs, output, commands and messages are then transferred between 
the two nodes, without any further operator involvement. 


$S LNE2 $S LNES 
SSN, LNE2 <or> SSN, LNES 


SNA Sessions: The process is similar with SNA, with the following additions: 


Start VTAM (after JES2 1s up). 

Activate the various physical and logical SNA units. 
Start the JES2-VTAM interface. 

Specify the APPLID on the $SN command. 


ole a ae 


Either side can issue the $SN command, as long as the lines are started on both 
sides. 
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JES3-JES2 
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JES2 NJE 


Node "A" Node "B" 
Applid "AAPPL"™ Applid "BAPPL"™ 


V NET,ACT,... V NET,ACT,... 
$S LGNI1 $S LGN1 

$S LNE?7 $S LNE8& 
$SN,LNE7,A=BAPPL <or> $SN,LNE8 


BSC (or CTC) Connections: On the JES3 side, start the NJE console oper- 
ations once for the life of JES3 (3X NJECONS). 


On the JES2 side of the connection, start the logical lines ($$ LNEnnn) before 
networking can begin. 


Then the NJE task is called for the connection (#X NJE,NODE=nodename) on 
the JES3 side, or $SN on the JES2 side. 


JES3 Node JES2 Node 


*X NJECONS $S LNEnnn 
*¥X NJE,NODE=JES2node <or> $SN,LNEnnn 


SNA Connections: On the JES3 side, SNA connections are made by the 
MVS/BDT component. The scenario 1s similar to the BSC procedures with the 
addition of starting MVS/BDT and issuing a few BDT commands. 


The JES2 side of the connection is similar to BSC with the addition of starting 
VTAM, the JES2-VTAM interface, and the logical line 1s a SNA line. 


Networking is actually started by the BDI command +S 
SNA, NODE=nodename or the JES2 command $SN. 


RSCS-JES2 


JES3 Node JES2 Node 


S BDT 
*X NJECONS 
+X SNA $S LGNI1 
$S LNEnnn 
+S SNA,NODE=JES2Node <or> $SN,LNEnnn 


There are no order dependencies between the two nodes. Once the BDT START 
SNA command is issued, the link will be retried until networking is successfully 
established. 


BSC (or CTC) Connections: On the VM system, load and initialize RSCS and 
initialize the communication controllers and ports. 


On the JES2 side of the connection, start the logical lines ($¢S LNEnnn) before 
networking can begin. 


Then the NJE connection is started at either end by the RSCS START command 
or the JES2 $SN command. 


RSCS Node JES2 Node 


<RSCS user signs on> 


ENABLE cuu $S LNEnnn 
RSCS START JES2node <or> $SN,LNEnnn 


There are no order dependencies between the two nodes. Once the RSCS 
START command 1s issued, the link will be retried until the link is successfully 
established. 


SNA Connections: In addition to the above procedures, start VTAM and the 
RSCS/VTAM interface before the links are started. 
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POWER-JES2 
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JES2 NJE 


RSCS Node JES2 Node 
CRSCSApp1) CJES2App1 ) 


VTAM START 


RSCS console: V NET,ACT, 
GLOBAL LOADLIB RSCS 
FILEDEF config ... 
FILEDEF dest sca 
LOADCMD RSCS' DMTMAN 
RSCS_ INIT 


3S LGNI1 
RSCS NETWORK START APPL RSCSApp1 $S LNEnnn 
RSCS START JES2Node LUN JES2App1 <or> $SN,LNEnnn 


Many of the RSCS commands can be in a PROFILE or EXEC, but are shown 
here for illustration. 


BSC (or CTC) Connections: On the POWER side, start the Network Defi- 
nition Table 


On the JES2 side of the connection, start the logical lines ($S LNEnnn) before 
networking can begin. 


Then networking can be started by POWER (PSTART PNET,nodename,...) 
or JES2 ($SN). 


POWER Node JES2 Node 


SET PNET=NDTname 
CAUTOSTART only) 
$S LNEnnn 


PSTART PNET,JES2node,... <or> $SN,LNEnnn 


There are no order dependencies between the two nodes. Once the PSTART 
command is issued, the session will be retried until networking is successfully 
established. 


SNA Connections: With SNA sessions, the procedures are the same, except you 
must start VIAM and activate the resources before issuing the (PSTART) 
command. 


Network Shut-Down 


JES2 Connections 


JES3 Shut-Down 


RSCS Shut-Down 


POWER Shut-Down 


Normal Line Termination: Either side of the connection or session can initiate 
temination. The $PLNE (drain line) command can be used to stop the logical 
line(s) used for NJE. 

Immediate Termination: To stop the NJE lines immediately, follow the drain 
line command(s) with the $ELNE (restart line) command. The purpose of 
abnormal termination is to clear the session as quickly as possible. 


After all NJE lines are stopped, use the $PLGN1 command to bring down the 
JES2/VTAM interface. Finally, deactivate VTAM resources and stop VTAM. 


Also, the $PJES2, ABEND will bring down JES2 as well as all the NJE lines. 


There is no single command in JES3 to stop all NJE sessions, but the xC, line 
(cancel line) command can be used to stop each line. 


Use the SHUTDOWN command to drain all NJE connections gracefully. To stop 
the NJE lines immediately, use SHUTDOWN QUICK. To deactivate an individual 
line, use the DRAIN or STOP command to bring it down immediately. 

The FORCE command 1s not recommended as it ABENDs the links. 


For SNA sessions, use NETWORK HALT <QUICK>. 


Use the PSTOP PNET,nodeid command to stop specific NJE connections. 


There is also a PEND command to bnng down all PNET nodes as well as the 
entire VSE/POWER system. 
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Displaying the Network 


On JES2 Nodes 


On Other Nodes 


JES3 


On RSCS Nodes 
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JES2 NJE 


Nodes: $TN displays the network as seen by the local system. In response to 
this command, JES2 displays each node defined to the system, whether it is active 
or not, and how it is connected. Individual nodes, or ranges of node numbers, 
can be displayed by using the node number(s) as operands. 


Lines: Use $DU,LNES to display the status of all NJE and RJE lines and 
$DU, LNEnnn to display the status of specific lines. 


JES2-VTAM Interface: Use $DU,LGNS to display the status of LOGON] (and 
LOGON2 if defined). 


Send commands (in the language of the target nodes) to other nodes from a JES2 
node with a $N command. 


Nodes: Use the %*I NJE,NAME=nodename command to display individual 
nodes. 


BSC Lines: In addition, use the LINE or SNDR operands to display the status of 
lines or logical senders associated with that node. 


MVS/BDT: INQUIRY NODE=ALL displays all SNA nodes (both FTF and 
NJE) This will not show any BSC NJE nodes, for which the JES3 command xI 
NJE must still be used. The NODE= parameter limits the display to a particular 
node. 


Nodes: To display a particular node line and other status, use the Query 
locid command. 


Lines: To display all active RSCS lines, including NJE and other lines, use the 
Query SYstem Active command. To display all links (1.e., lines) defined to 
the system, (including NJE and other lines), use the Query SYstem Links 
command. 


To display a particular line defined to the system and their default attributes, use 
the various forms of the Query lLinkid command. 


Routes: To display all routes (i.e., paths) defined to the system, use the Query 
SYstem Routes command. 


On POWER Nodes 


To display the network definition table that is currently in use for NJE, use the 
PDISPLAY PNET,ALL command. (There are more operands on this command 
for more specific displays.) 


Nodes: To display the status of a particular node, use the PINQUIRE 
NODE=nodeid command. 


Lines: To display all lines used by NJE and RJE terminals, use PINQUIRE 
ALL. To display a particular line, use PINQUIRE lineaddr | luname. 


Altering Nodes and Paths 


On JES2 Nodes 


On JES3 Nodes 


On RSCS Nodes 


JES2 has a dynamic network path manager function which keeps a real-time, 
accurate picture of all nodal connections, if they are all JES2 nodes. For networks 
of mixed nodes, however, this only works for the JES2 nodes which are either 
directly attached or connected through other JES2 nodes. There is no path 
manager on non-JES2 nodes. 


The JES2 operator can not dynamically change pre-defined connections without 
the $CONNECT modification mentioned above. To change these connections 
(which are required for non-JES2 nodes), JES2 must be restarted with different 
CONNECT initialization statements. Nodes and paths can not be added, deleted, 
or renamed without a warmstart of JES2 with different initialization statements. 


Nodes and lines can not be added, deleted, or renamed by the operator. 
However, nodes may be changed between BSC and SNA. 


Paths: Only one path to a given destination is permitted. If a node or path in 
the network is down for an extended period of time, the operator can alter the 
routing tables with the *F NJE,NAME=nodel1,PATH=node2 command. 


The RSCS operator has complete control over all the NJE resources and can 
alter or redefine them with commands. 


Nodes: To define a new node or change the attributes of an existing node, use 


the DEFine linkid command. To delete an existing node, use the DELete 
Llinkid command. 
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On POWER Nodes 


3-10 


JES2 NJE 


Paths: To define or modify a path to a non-adjacent node, use the ROUte 
locid TO link command. To delete a path to a non-adjacent node, use the 
ROUte locid OFF command. 


Only one path to a given destination 1s permitted. The operator can alter the 
routing tables with the ROUTE dest TO link command. Ifa link goes down, 
RSCS will invoke an EXEC with the name of the failing link if one exists. This 
EXEC could issue the above commands to change the paths. 


The REROUTE can be used to forward all files recerved on this node to another 
destination. 


All node definitions and routing information must be defined by the user with the 
aid of the PNODE macro, assembled in the Network Definition Table (NDT), 
and loaded during PNET initialization. If required, use the PLOAD PNET,ndt 
operator command to dynamically replace this table while POWER is active. 


You can only specify one path and an alternate to a given destination. If the 
primary route is not active, but the secondary route is active, then the secondary 
route is chosen. Both routes will NOT be used together, i.e. as soon as the 
primary route is available all new transmissions will be sent over the primary 
route and the secondary route will cease to be used as soon as the current trans- 
mission finishes. If a node or path in the network is down for an extended period 
of time, the operator can alter the routing tables by reconfiguring the network 
definition table and reloading it with the PLOAD command. 


Controlling Network Devices 


On a JES2 Node 


There are many differences between the various NJE systems in the level of 
control that operators can have on NJE connections. Some NJE implementa- 
tions exercise control at the line level, some at the node or destination level, and 
some at the particular stream level within a line. Many affect control at more 
than one of these levels. These streams may be for SYSIN or SYSOUT jobs. 
(Streams for commands and messages cannot be controlled.) 


The JES2 operator can control individual lines to adjacent nodes and individual 
transmitters and receivers on each of those lines. There is no control on a desti- 
nation basis, but the operator can specify that all jobs from a particular node can 
be automatically put in hold status when received. 


Lines and Sessions: JES2 allows any number of lines to other nodes in the NJE 
network, including parallel lines to adjacent nodes, but only one session 1s per- 
mitted between any two JES2 systems. (See “Second Session Between Two 
JES2 Systems” on page B-2 for exceptions.) 


Using SNA, a session to another NJE node appears to the operator as a logical 
line. This way, other SNA/NJE nodes appear to be directly attached to this node 
even though there may not be a direct link between the two hosts. 


Use the $DU,LNEnnnn JES2 command to display lines (and sessions); use the 
$S, $P, and $E commands to start, stop or restart them respectively. Also, the 
$T command turns on or off various types of tracing on individual lines. 


Transmitters and Receivers: Depending on the setting of JES2 initialization 
parameters, there can be various numbers of the following logical devices enabled 
on each active NJE line: 


Job Receiver (JRn) 

Job Transmitter (JTn) 
Sysout Receiver (SRn) 
Sysout Transmitter (SRn) 


Each one of these logical transmitters and receivers can be displayed and con- 
trolled independently with the following commands: 


Display $DU,Lnn. JT1,Lmm.SR2,... 
Drain $P Lnn.JT1,Lmm.SR2,... 
Restart $E Lnn.JT1,Lmm.SR2,... 


Start $S Lnn.JT1,Lmm.SR2,... 
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On JES3 Nodes 


On RSCS Nodes 


On POWER Nodes 


3-12 


JES2 NJE 


The JES3 operator can control individual lines to adjacent nodes; transmitters are 
controlled on a node or destination basis, and receivers are controlled on a line 
basis. 


Lines: The JES3 operator can start (%X NJE, NAME=nodename , 
LINE=linename) or stop (¥C linename) individual lines. 


Transmitters: The operator can place a remote node in hold status with the ¥F 
NJE,NAME=nodename,HOLD command. All jobs scheduled for that node and 
subsequent jobs entering the system destined for that node will not be trans- 
mitted. The operator can later release the node from hold status, then release the 
individual jobs. 


Receivers: The operator can stop all job and SYSOUT reception on a given line 
with the *S linename,NORCV command and later re-enable it with the *S 
Linename , RCV command. 


Lines: Use the START linkid TYPE NJE | SNANJE command to start a 
particular link and the DRAIN and STOP commands to deactivate the link. 


Transmitters: Use the HOLD and FREE commands to suspend and resume trans- 
mission on a NJE line. 


RSCS (Version 2) supports multiple streams, and allows different transmission 
algorithms on each link. 


The operator can control NJE connections on a node basis; transmitters and 
receivers are controlled with the PACT node and PDRAIN node commands. 
Use the PSTART or PSTOP command to start or stop the line (BSC) or session 
(SNA). Also, the PFLUSH PNET,node,TRn command with the HOLD 
command will also hold a particular transmitter task, but allow processing to 
continue with other jobs. 


Network Problem Determination 


Connection Problems 


Make certain that the NJE connection is fully activated at both ends. Many fail- 
ures in connecting may appear only at one end, while the other end appears to be 
connected. 


If the systems do not successfully connect, check the following: 


JES2 (and VTAM) Active: "Ensure that JES2 is active and started ($$) and 
VTAM has been started and initialized if SNA connections are to be used. 


Node names: Ensure that node names match each other on both sides. 


Node numbers: "Ensure that node numbers and member numbers (1.e., MAS 
system IDs) match any CONNECT initialization statements. (Node numbers do 
not have to match definitions on other nodes.) If the connection is pre-defined, 
it should be pre-defined on both ends. 


Application IDs: For SNA NJE, ensure that they match the VTAM definitions 
and match each other on both sides. 


Check the LOGONn initialization statement used to define the APPLID name of 
JES2 to VTAM. The one for the NJE session started by this node must be 
defined by the LOGON1 statement. (LOGON2 can define an ACB used by another 
node.) 


Communication Facilities: Check the teleprocessing lines, controllers, modems 
and switches to ensure that they are enabled. If it is a SNA networking session, 
ensure that the Physical and Logical Units are active for the session that JES2 
will use. 


VTAM/NCP Parameters: If it isa SNA session, the VTAMLST members must 
agree for the subareas, cross-domain resource and resource managers, paths, etc. 
If you encounter a “session not bound” error, then try the session without any (or 


the default) LOGMODE table entry. 


Passwords: With JES2 BSC networking, there may be two passwords: the Line 
Password specified on the LINEnnn initialization statement, and the Node Pass- 
word specified on the Nnnn initialization statement. If the other node is not a 
JES2 node, check the definition of passwords to ensure that they match. (With 
SNA NJE sessions, JES2 does not use line passwords.) 


TOD Clocks: Ensure the TOD clocks on the two systems are specified in GMT 
and that the correct day, month and year are specified at both nodes. Otherwise, 
a future TOD value in the Nodes Attached Table (NAT) may prevent a suc- 
cessful path manger sign-on. 


In a multi-access spool (MAS) complex, also ensure that the clocks in the various 


members are synchronized within the value set by the SYNCTOL parameter on 
the MASDEF initialization parameter. 
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Files Fail to Transfer 
This can be due to several factors: 


The NJE connection was not correctly defined or started. 
Routing parameters are not correct. 

The line is down or the session broken. 

No work is available for transmission. 


First ensure that the NJE connection is fully activated. Often, when the con- 
nection appears to be operational at one end, but not transmitting or receiving 
files, the other end was not correctly defined. 


Run some simple tests, such as sending a message or command to that other 
node. Then try sending a small test job or file (with a high priority) to determine 


if the problem 1s in the files or the connection. 


Transmission Queues Growing: This may be due to the reasons above, or a 
heavy influx of NJE work. 


Routing Problems 
Be alert to “ping-ponging”, or files bouncing back and forth between two nodes 
without getting to the destination. This is usually caused by incorrect routing 
tables, or multiple NJE connections being down. 


Missing Files or Jobs 


If an end-user calls and says that expected jobs can not be found, consider the 
following procedure: 


1. Look for the job with the $D*'jobname’ command on the local system. 

2. Look for the job on other JES2 nodes with the $Nxx3;$D'jobname" or 
$GD, 'jobname'’,Jnnnn commands. (If the network is large, then the $GD 
command should be sent to specific nodes instead of broadcast to the entire 
network.) 


3. Ask the user to re-submit the job and both of you can track its progress. 


4. If still not found, ask a systems programmer to examine the SYSLOGs and 
SME records of the possible nodes involved. 
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Job Tracking and Control 


Monitoring Transmission Queues 


SYSIN jobs are transmitted from the submitting (origin) node to the execution 
node by NJE, sometimes going through several store-and-forward (intermediate) 
nodes. Also, SYSOUT jobs are transmitted from the execution (or creation) 
node to the destination, sometimes going through intermediate nodes.! 


At each step of the way, the jobs are queued for transmission and selected in 
turn. Operators at each of the intermediate nodes can display these queues to 


monitor the progress of individual jobs or the work-flow in general. 


Usually, jobs and output are queued for transmission in first-in-first-out (FIFO) 
order within prionity. 


Job Transmission Messages 


Below is a table of operator messages that are issued by the various systems for 
transmitting and receiving NJE jobs: 


IAT9190 
IAT9191 


TAT9127 
$HASP165 


$HASP100 | IAT9124 


SYSOUT Jobs cae 
- Queued for Transmission on Exe- 
cution Node 


- Transmitted to Next Node $HASP530 | IAT9190 
IAT9191 

$HASP540 
- Received at Destination Node SHASP540 | IAT9123 
IAT9127 


Figure 3-1. Transmission Messages by System 


RSCS: These messages go the the RSCS Operator, not the System Operator. 
Also, there is no distinction between SYSIN and SYSOUT jobs. The “execution 
node” for SYSOUT jobs implies “sending node” for RSCS. 


1 Even if SNA facilities are used, jobs can be routed through intermediate nodes. 


2 See APAR OYO5811. 
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Notification Messages 


Unsolicited messages are sent to the originating and target user-ids at various 
points of NJE transmission. See “Notification and Tracking” on page 4-35 for 
specifics. 


Finding and Controlling Jobs 


If not on the local operator’s system, commands can be sent to other nodes to 
determine if a particular job is there. From a JES2 system, this can be done with 
“global” or system-independent commands. Otherwise, use a “send operator 
command” command, in the command language of the target system. See 
‘Sending Commands and Messages” on page 3-29. 


Once a job is found on another node, commands to Re-Route, Hold, Release 
and Cancel Jobs can be sent to that node. 
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Displaying Transmission Queues 


JES2 Displays 


JES3 Displays 


RSCS Displays 


POWER Displays 


The following commands display the number and/or names of jobs in the NJE 
transmission queues according to the system. 


Queue Size: $DQ,Q=XMT... displays the number of jobs on the job trans- 
mission queue with the $HASP645 message. $DQ,R=... displays the number 
of jobs on the SYSOUT or job transmission queues with the $HASP643 or 
SHAS P645 message. 


$DF,R=... displays the number of SYSOUT data set groups by destination 
with the $HASP621 message. 


List Jobs in Queue: $DN,»Q=XMT... displays the names of all jobs on the job 
transmission queues with the $HASP608 message. $DN,R=... displays the 
names of all jobs on the SYSOUT or job transmission queues. 


SDSF: Use System Display and Search Facility (SDSF) to display the input, 
output or held queue by nodal route code with the DEST command. Ia dis- 
plays jobs on the “X MIT” queue. 


The operator can display the names of jobs queued for NJE transmission. 
However, neither the length of these queues, nor number of records to transmit 
can be displayed. 


%I A D=NJESND displays jobs queued for transmission. This includes both 
SYSIN jobs and SYSOUT. 


BDT (SNA): With the SNA/NJE Enhancement, *I U,Q=BDT,BT= displays 
jobs on the NJE transmission queues. 


QUERY linkid with the appropriate parameters displays the transmission queue 
for a particular linkid. 


All displays are for a particular linkid; there is no display command for all NJE 
links on the system. 


PDISPLAY XMT displays the job transmission queue for a particular destination, 
with the TNODE, TUSER, FNODE and FUSER parameters used to specify a 
particular destination node and user-id or origin node and userid. 
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Transmission Priorities 


JES2 


JES3 


RSCS 
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JES2 NJE 


SYSIN Jobs: The job prionty is used for determining job (SYSIN) transmission 
pnonty on JES2 nodes. 


SYSOUT Jobs: There is only one network queue for output which is ordered 
prionty within destination (node and remote). Output is transmitted FIFO within 
destination within pnonty.4 The output priority is used for determining the trans- 
mission pnority of job output on JES2, however, when a SYSOUT data set is 
selected (via $4GET) for transmission, JES2 will attempt to gather all SYSOUT 
data sets for that job. An exception to this is SPIN data sets which are trans- 
mitted separately. 


Re-Ordering Transmission Queues: $TJ is used to change the pniority of a par- 
ticular job. $TOJ is used to change the pnonty of SYSOUT files. 


BSC transmission scheduling 1s FIFO for all transmissions to o through an adja- 
cent node. This is true for both Job SYSIN and SYSOUT transmissions. If the 
installation has 2 streams active to the adjacent node, then transmission is FIFO 
within stream type. 


SNA transmission is FIFO by pnonity within transmission type. For a SYSIN 
Job transmission, the priority is taken from the submitting job’s priority as speci- 
fied on the JOB card or through installation defaults. For SYSOUT trans- 
mission, the priority us taken from the executing job’s priority as specified on the 
job card or through installation defaults. 


Jobs and output files are managed on a single transmission queue. There is no 
difference between job-streams and job output; they all look to RSCS as print 
and punch files. They are all ordered by file size within pnonty except for pn- 
onity 1. In pnonty 1, they are maintained in FIFO (first-in-first-out) order. In 
RSCS, the pnonty is represented by a decimal number from 0 (the highest) to 99 
(the lowest). In the network job header, the pnonity is indicated in the field 
NJHGPRIO and is a binary value from 0 (lowest) to 15 (highest). The priority 
is either set by the user on the TAG command, or is translated from and to the 
job header according to the following table: 


: Fixed with APAR OZ84420. Before this fix, output was transmitted in priority 
sequence within destination. 


POWER 


Network-to-RSCS 


Priority 


0 to 99 (lowest) 


1 to 92 
2 to 85 
3 to 78 
4 to 71 
5 to 64 
6 to 57 
7 to 50 
8 to 44 
9 to 37 
10 to 31 
11 to 27 
12 to 19 
13 to 12 
14 to 6 


15 to 0 (highest) 


Figure 3-2. 


RSCS-to-Network 
Priority 
90-99 to 0 
84-89 to 1 
78-83 to 2 
72-77 to 3 
66-71 to 4 
60-65 to 5 
54-59 to 6 
48-53 to7 
42-47 to 8 
36-41 to 9 
30-35 to 10 
24-29 to 11 
18-13 to 12 
12-17 to 13 
6-11 to 14 
0-5 to 15 


RSCS Priority Translation 


Your installation can extend the transmission algorithms. See RSCS Networking 
Exit Customization, LY24-5240 (RSCS Networking Planning and Installation, 
SH24-5057 for RSCS Version 2.1) for details. 


Re-Ordering Transmission Queues: The ORDER command causes specific files to 
be placed at the start (first) of the specific link’s transmission queue. 


In the POWER XMT (transmission) queue, jobs and output are queued in pn- 
ority sequence. Jobs are then selected in FIFO sequence within pnonty. The 
priority is indicated by a decimal number from 0 (the lowest) to 9 (the highest). 
In the network job header, the priority is indicated in the field NJHGPRIO and 
is a binary value from 0 (lowest) to 15 (highest). The priority is either set by the 
user or 1S translated from the job header based on the following table: 


Network-to-POWER 


Priority 


0 to O (lowest) 


1 to 1 

2-3 to 2 
4-5 to 3 
6-7 to 4 
8-9 to 5 
10 to 6 
11-12 to 7 
13-14 to 8 
15 to 9 


Figure 3-3. 


POWER-to-Network 
Priority 

0 to 0 

1 to l 

2 to 3 

3 to 5 
4to7 

5 to 8 

6 to 10 
7 to 12 
8 to 13 
9 to 15 


POWER Priority Translation 


Re-Ordering Transmission Queues: Use PALTER to change the pnonty of a par- 
ticular job, and use PHOLD and PRELEASE to disable and enable a job for trans- 


mission. 
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Displaying Jobs in the Network 


Global Commands 


JES2 Displays 


JES3 Displays 


RSCS Displays 
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JES2 NJE 


If not on the local operator’s system, the $GD command interrogates a given 
node, or all nodes for the presence of a particular job. JES2 is the only system 
that sends this command; only JES2, JES3 and RSCS interpret them. 


The $GD command, without any node specification, is sent to all nodes in the 
network, so be careful of issuing this command without a specific nodename in a 
large network. 


See Figure 3-4 on page 3-24 for the translation of $GD command to local system 
commands. 


$DJ displays a job (or range of jobs) and shows the execution node if awaiting 
transmission as a job, or default print and punch destinations if awaiting output. 
This command does not show the routing of individual pieces of output. See the 
descnption of message $HASP608 for details. 


$LJnnn, ALL displays all the attnbutes of particular output groups or job output 
elements (JOEs), including destination via the $HASP688 message. 


$DF,R=Nnnn... displays the number of SYSOUT jobs queued and their attn- 
butes queued by destination, but does not list the particular job names. 


STCs and TSUs: While this section is onented to jobs, there are equivalent 
commands for started tasks ($DS, $LS, $TOS) and for time sharing (TSO) users 
($DT, $LT, $TOT) 


SDSF: For authorized TSO users, SDSF can also display jobs (SYSIN and 
SYSOUT) on the local JES2 queues. 


*I J displays all jobs. I U displays jobs on the WIR or HOLD queue, but 
is not supported from remote nodes unless user exit 35 is coded. 


QUERY FILE spoolid displays the attnbutes of a particular file, (including its 
routing destination) using its spoolid. You cannot display a file by its MVS (or 
POWER) jobname. 


POWER Displays 


The PDISPLAY command displays a particular job, jobs on a specific queue 
(XMT, LST, PUN, RDR), or jobs with a given ongin or destination. This 
command has many different formats; see the VSE/POWER Installation and 
Operations Guide for details. 
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Re-Routing Jobs and SYSOUT 


Global Commands 


JES2 Commands 


JES3 Commands 


RSCS Commands 
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$GR re-routcs a job at another node. This command is only honored at other 
JES2 nodes or RSCS nodes. JES3 and POWER nodes do not honor this 
command. See Figure 3-4 on page 3-24 for the affect on other systems. 


$R rce-routes a job or its output on a JES2 node. $TOVJ alters the destination of 
a particular output group. The form “node:userid” cannot be specified; any 
usend routing information 1s lost with this command. 


Alternatively, the opcrator may change the route-code of a given pnnter with the 
$T PRTnnn, R= command. 


Held Jobs: Jobs in hold status awaiting execution (or conversion) cannot be re- 
routed without being manually released, and will not be automatically held at the 
new destination. 


Held SYSOUT: Output held for TSO output (or other reasons) can be re- 
routed to another NJE node; however, held output destined for another node 
that is re-routed to the local node before being transmitted will not be held 
locally. 


Default Routing: $T RDRn,X= sects or changes the input device default cxe- 
cution node, print node or punch node. This applies to local (RDRn) or remote 
(Rmmm.RDn) readers, but not to internal readers. 


Jobs (both SYSIN and SYSOUT) can be re-routed with the SNA/NJE Enhance- 
ment with the *X NJEROUT command. (Previously, jobs on the JES3 execution 
queue could not be re-routed to another destination.) The only restriction now 1s 
that SYSIN jobs cannot be re-routed if they are queued for local execution. 


SYSOUT jobs can be re-routed with the ¥F U,...,ND=dest command. 


The TRANSFER command redirects a file to another destination. (With RSCS 
Version 1, this only worked to another RSCS node.) 


See also the REROUTE command to set up a forwarding mechanism at an RSCS 
node. 


POWER Commands 


PALTER queue, jobname,NODE=...,USER=... re-routes jobs or output to 
another node. 
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Controlling Jobs and Output 


Global Commands 


Function | JES2 Effect Effect Effect Effect 
Command on JES2 on JES3 on RSCS on POWER 

Display Job $G Dnode,’job’ *J J=job Q FILE splid (not supported) 
Route Job $G Rnode,XEQ,’job’ $RXEQ,J =job,D =| (not supported) TRAN link splid (not supported) 

TO node 
Route Output $G Rnode,OUT, ’job’ $RALL,J = job,D =| (not supported’ TRAN link splid (not supported) 

TO node user 
Hold Job $G Hnode,’job’ $H/’job’ *F,J=job,H CH jobid HOld (not supported) 

$GAnode,’job’ *F,J=job,R CH jobid NOH (not supported) 

Cancel Job $GCnode,’jname’ *F,J = job,C[P] PURge jobid 


If the job is “owned” by the particular system or remote workstation, you can 
Hold, Release or Cancel it with either the appropnate local JES2 command or 
with a global command. 


The following “global” or system-independent commands can be used to hold, 
release and cancel jobs at other nodes. 


e $GH holds a job at that node. 
e $GA releases a job at that node. 
e $GC cancels a job at that node. 


Note the following precautions: 
e You must have job-level authority on the target node. 


e If there is more than one job with the same name, it must be further quali- 
fied by the job number. 


e If the job did not onginate from your node, you must specify the O = node- 
name parameter to identify the submitting node. 


Below is a table of “global” operator commands. They are sent as a formatted 
control block, so that any system can decipher them without having to under- 
stand the command syntax of the originating system. They are only fully sup- 
ported on JES2 systems, but several other systems can process them if received 
from a (JES2) system. 


(not supported) 


Figure 3-4. Global Commands 
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JES2 Commands 


JES3 Commands 


RSCS Commands 


POWER Commands 


$HJ holds the job on any queue. Jobs in execution continue running and output 
already on the JES2 hardcopy queue are still available for pnnting. Also, output 
on the XMIT queue 1s still available for transmission. 


$AJ releases a held job on any queue. $0OJ releases held output data sets for a 
job. 


$CJ cancels a job or output group. $PJ purges a job’s output, or a specified 
class of output for that job. $OJ cancels held output data sets for a job. 


$TJ and $TOJ,...»S=Y are invalid from other NJE nodes (unless your node 
has Network authonty). Therefore, to alter a job’s class, prionty, affinity, or hold 
an output group, you must ask the local system operator to issue the command. 

STCs and TSUs: Again, there are equivalent commands for started tasks ($CS, 


$PS, $0S, $TS, $TOS, etc.) and for tume shanng (TSO) users ($CT, $PT, $OT, 
$TT, $TOT, etc.). 


Spool files can be held, released and purged with the *F J= command. 


Spool files can be held and released with the CHANGE command and purged with 
the PURGE command. 


For jobs on the local POWER queues, use the following commands: 
e PHOLD places the job on the specified queue in the Hold or Leave state. 


e PRELEASE makes the job on the specified queue ready for execution, 
printing/punching or transmission 


e PCANCEL cancels the execution of a currently running job. 
e PDELETE deletes the job from a local queue. 


e PALTER changes some of the attributes associated with the job in the speci- 
fied queue. 


For jobs on remote nodes, the PXMIT command sends a command in the syntax 
of the target system. Global commands are not supported on POWER. 
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Transmission Recovery 


Undefined Destinations 


JES2 Handling 
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JES2 NJE 


Jobs (SYSIN and SYSOUT) are handled on a store and forward basis. Respon- 
sibility for a unit of work does not pass from a transmitting node until it receives 
positive acknowledgment to the end-of-file which follows the Job Trailer Record. 
If transmission is interrupted before that point, the receiver discards any data it 
has received so far, and the transmitter requeues the entire job for retransmission 
from the beginning. 


If a line failure occurs before the transmitter has sent end of file, the transmitter 
will requeue its work for transmission. If a line failure occurs after the end of file 
is sent but before acknowledgment is received, the work is requeued in ‘HOLD’ 
status to avoid immediate retransmission. JES2 issues a message to help the 
operator ascertain whether the receiving system successfully received the entire 
job before releasing it or canceling it. This is done to prevent duplicate jobs on 
the receiving system. 


Occasionally a destination is misspelled or specified incorrectly. This can be an 
error by an end-user in a JCL statement or by a systems programmer in defining 
the network destinations. This section describes what each of the NJE systems 
do when encountering a file destined for an unknown location. 


Locally-submitted jobs: A job submitted to JES2 with an unknown node name 
will be failed with a JCL/JECL error on the submitting node. If the user/remote 
name can’t be interpreted as a remote name, it is taken to be a TSO/VM usend. 


When receiving SYSIN jobs: An unknown execution node name causes the job 
to be executed on the receiving node. The execution userid 1s ignored. 


No message is issued to the local operator or submitting user. If the job specifies 
the unknown node name in its JCL it will be failed as above with an error 
message sent back to the ongin node/user. 


An unknown origin node name (in the network job header) is changed to the 
receiving node’s name (in the JQE) although the received name remains in the 
job header, JCT and SMF records. An unknown ongin remote/user name 1s 
changed to ‘LOCAL’ internally. 


When receiving SYSOUT jobs: Unknown origin node, origin remote/user, exe- 
cution node, and/or execution remote/user names (in the network job header) are 
reported to SMF, but are converted internally to the receiving node’s name and 
‘LOCAL’. 


An unknown destination node and/or remote/user name causes the SYSOUT to 
be printed on the receiving node locally. No message is generated in this case. 


JES3 Handling 


RSCS Handling 


If a local user submits a job for execution at an unknown node, the job is failed 
with a JECL error. 


If a local user submits and executes a job, with the SYSOUT destined for an 
unknown node, JES3 assumes that the destination is not NJE at all, but is RJE 
output. In this case, the job could sit on spool forever. 


If JES3 receives a stream for store and forward for an unknown node, the job is 
placed in operator hold and the local operator receives as error message. If the 
identified node is later defined to JES3, and the job is released, it will be for- 
warded. 


Finally, if JES3 receives a stream from an unknown node, the job is placed in 
operator hold and the local operator receives an error message. In this case, if the 
job is then released, it will continue with no other action. The error message 1s 
intended to be an alert for a possible infiltration attempt. 


JES3/BDT Handling: For outbound work from the local node, BDT only gets 
involved if JES3 gives BDT a job and BDT doesn’t know about the next destina- 
tion. In this obscure case, the system programmer has probably mis-specified the 
definitions and is responsible for fixing them. BDT will reject the job (will not 
place it on its queue) and JES3 will hold the job. 


For inbound work from other nodes, BDT does not perform any checking of the 
destination names. 


For SYSOUT to be processed at the local node, there is no notion of undefined 
user in this case. If a value exists in NDHGRMT, it is assumed to be a remote 
workstation user and queue it accordingly. It is possible for the work to remain 
on spool forever if the “remote user” is not known. 


For an unknown node, RSCS will check to see if the file onginator 1s local to 
this node, or if the file with the unkr-wn destination is a store and forward file. 
For a local origin file, RSCS gives tne file back to the user. For a store and 
forward file, RSCS purges it. 


When a file reaches the destination and RSCS cannot find the user, the file is 
printed or punched on the local system. 


In all cases, RSCS notifies the onginating of the error. 


RSCS makes no checks on the ongination node (for example, to make sure it 
knows of the onginating node id). 
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POWER Handling 
If POWER receives a job with an undefined destination name, it places the job 
or job output in “hold” in the local reader/output queue and tries to inform the 
job onginator. 
If job output arrives from another node destined for an unknown user, that 
output stays on spool forever, unless the system operator disposes them. This is 
because VSE/POWER does not have a user directory and does not distinguish 
between ICCF/CMS users and logical printer names. 
POWER does not check ongin node or ongin usend. 

Summary of Product Actions 
Below is a summary of what each NJE product does when it receives a file which 
falls into one of these cases. This list only describes actions for SYSIN and 
SYSOUT jobs; NMRs are not included. 
This should not be confused with the sending of a job to a destination node 


which is defined, but not reachable. In that case, it is held on spool until the 
node becomes reachable. 


Unknown Node or User JES2 JES3 RSCS |}POWER sid 


Unknown Dest’n Node Fail Job (N) Fail Job (N) Return to Sender (N) Hold Locally (N) 
- Local Origin Print Output Locally Leave Output on Spool 

Unknown Dest’n Node Execute Job (1) Hold Job (M) Purge (N) Hold Job (N) 

- Remote Origin Print Output Locally Leave Output on Spool 

Unknown Dest’n Userid Print Locally Leave on Spool Print Locally (N) Leave on Spool 

at Destination Node 

Unknown Origin Userid Chg. Origin to Local No Check No Check No Check 

- Local Node 

Unknown Origin Node Chg. Origin to Local Hold (M) No Check No Check 


Figure 3-5. Unknown Destination Handling 


Notes 

(M) Message issued to Operator 

(N) Notification Message sent to Originator 

(1) If there is an undefined node name in the JCL, the job is failed and an error message returned to the origin node/user. 
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Sending Commands and Messages 


From JES2 


In NJE, commands and messages are transmitted as nodal message records 
(NMRs). In the case of commands, the text is intended to be executed on the 
recciving node. Messages are intended to be displayed on the recciving system. In 
gencral, all systems with command capability must have message capability in 
order to receive the output from the command. 


In JES2, NMRs are not stored and forwarded in the spool system. Ifa path does 
not exist to the next node, the NMR is discarded. If a command NMR 1s dis- 
carded, then a new NMR 1s routed back to the origin to inform the originator of 
the incomplete path. (In RSCS, the onginator 1s notified of the incomplete path 
even for message NMRs.) 


Sending Commands from JES2 


Formatted (Global) Commands: The following are supported by JES2: 


SG D Display job 
SG H Hold job 
SG A Release job 
SGC Cancel job 
SG R Route job 


JES2 assumes that destinations for the global route command are syntax checked 
at the receiving node. As a receiving node, JES2 will reject a global command if 
only the jobname is specified and JES2 finds more than one job with that 
jobname. A message is issued to the local console if the global command is 
rejected. See Figure 3-4 on page 3-24 for the effect of global commands on 
non-JES2 nodes. 


I‘or other commands, JES2 uses the $Nnnn;cmd-text command to send a 
command to another system. (Commands cannot be sent to a VM guestid on 
another node.) These are sent as “unformatted” commands because the 
command text is in free-form text, not formatted into specific ficlds. The 
command text must obviously be in the command syntax of the target system. 


Sending Messages from JES2 


To System Operators: JES2 can send messages to another node via the $DM 
operator command, but not to specific users on another node. ($Nnnn; SEND 
"msg-text*’ USER=(userid) would work if the sending system has 
NETWORK and SYSTEM authonty on the target system, but this level of 
authonty is not recommended.) 


In addition to solicited messages, JES2 will also send notification messages for 
certain job activities. See “JES2” on page 4-35 for details. 
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From Other Systems 


To a VM[CMS User: A JES2 system operator can use the following command 
to send a message to a CMS user on a VM node (node number ‘nnn’ to JES2): 


$Nnnn;MSG vmnode cmsuser message-text 


To an VSE[ICCF USER: A JES2 system operator can use the following 
command to send a message to a remote user on a VSE node (node number 
‘nnn’ to JES2): 


$Nnnn;PBRDCST *¥,userid, 'message-text' 


Sending Commands from JES3 


The SEND (or ¥T) command can be used to send commands to another node. 


Sending Messages from JES3 


A JES3 operator can use the ™MESSAGE, nodename. userid (alias ¥Z) to send 
a message to another node, or to a user on a VM node. It can also be used to 
send a message to a JES3 or JES2 RJP (RJE) workstation. 


Sending Commands from VM 


The CMD command can be used to send a command to another system. The 
format is CMD node cmd-text. 


The SMSG command can also be used; it must be used if the issuer of the 
command is not the RSCS operator. See “CMS Users” on page 4-32 for details. 
Commands cannot be sent to a VM guestid on another node. 


Sending Messages from VM 
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To Other System Operators: The MSG command can be used to send a message 
to another system. It must be issued in the MSG node RSCS_ msg-text 
format, where “RSCS” or “SYSTEM” can be used to indicate that the target is 
the System Operator, not some interactive user. The SMSG command can also be 
used; it must be used if the issuer of the command is not the RSCS operator. 


To Interactive Users: Messages can be sent to interactive users on other systems 
with the MSG command. (General users can use the SMSG command to ask 
RSCS to send the message.) See “CMS Users” on page 4-32 for details. 


Sending Commands from VSE 


The PXMIT node-id,cmd command (alias X) can be used to send a command 
to another system. Commands cannot be sent to a VM guestid on another node. 


Sending Messages from VSE 


The PBRDCST command (alias B) can be used to send a message to another 
system, or user thereon. 


Command /Message Transparency 


JES3 Transparency 


RSCS Transparency 


In general, commands and messages are forwarded without change through inter- 
mediate nodes. They are sent as Nodal Message Records (NMRs) and not 
stored on spool (unless necessary to bridge a JES2 MAS connection). Some 
exceptions to command and message transparency are listed below. For a 
detailed layout of the NMR, see the control block expansion in either N/E 
Formats & Protocols, GG22-9337, or the source of the JES2 $NMR macro. 


NMR Command Length Restriction: A command scent to JES3 1s placed into a 
buffer and inserted into the system with a JES3 INTERCOM macro. The 
INTERCOM buffer can be a maximum of 80 bytes. In addition, certain 
keywords are added to the commands, with the result that commands greater 
than 59 bytes long are rejected. 


To prevent needless command rejection, JES3 removes any trailing blanks from 
the command to reduce the length pnor to checking for the 59 byte limitation. 


JES3 Use of the Nodal Message Record (NMR): A field exists in the NMR 
which, for messages, designates the destination. This 8-byte field (NMROUT) is 
redefined several times to indicate a userid, a remote, or a console destination. 
The console destination usually has meaning only for command responses for a 
command that onginated at a specific console. For JES3, the console destination 
always designates a JES3 console, not an MCS console. Therefore, only two 
bytes are required to contain the JES3 console number. This console number 1s 
placed in the field NMRROUT, which is the second two bytes of the 8-byte des- 
tination field. 


RSCS does not store and forward all fields in the NMR record. Only TO and 
FROM nodes and TO and FROM userids are handled as well as the message or 
command text. When the NMR record is used to contain console ids, logical 
routing information and node qualifiers, this information is lost if the NMR 
record is sent through an RSCS node. Fields which are not supported are 
NMRTOQUL, NMRFMQUL, NMRUCM, NMRDESC and most other redefi- 
nitions of NMROUT except for userid or remote id. 
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Global Commands through VM Nodes: RSCS Networking does not support 
global (1.e., formatted) commands which onginate at its node. It will correctly 
forward formatted commands received from another NJE node. It also will 
receive and translate formatted commands into an equivalent RSCS command. 


Fields NMURLEVEL and NMRPRIO are always set to 7 when an NMR is for- 
warded regardless of what they contained when RSCS received the record. 


For messages containing a destination userid, NMRFLAGW and NMRFLAGT 
fields are both always turned on for Version 2.1 and earlier releases. Only 
NMRFLAGT its turned on for RSCS Version 2.2. This will cause messages des- 
tined for TSO users on JES2 nodes to be successfully displayed, but not those for 
RJE stations. 


Command Authorization 


Global Commands 


JES2 Authorization 


JES3 Authorization 


RSCS Authorization 


These cannot be sent from another node, imbedded in a $N command. 


JES2 supports four levels of command authonty, which can be specified on a 
node basis. The authonity levels are as follows: 


Job Node has the authonity to issue job-related commands. 

Device Node has the authority to issue device-related commands. 

System Node has the authonity to issue certain system commands. 

Network Node has the same authority as local consoles; this includes device, 
job and system authority. 


JES2 commands which control JES2 queues require both JOB and NETWORK 
authority. MVS commands require both SYSTEM and NETWORK authontty. 
See Appendix A “JES2 Command Summary” in JES2 Commands for remote 
NJE restrictions. 


Only the following commands can be sent to a JES3 node for execution; all other 
commands are invalid: 


%I J=jobname | jobno (display job status) 

%I B (display statistics for number of jobs waiting to be processed) 
%I Q (display status of all jobs) 

%F J=Jjobno,H (hold a job) 

%F J=Jjobno,R (release a job) 

%F J=jobno,C (cancel a job) 


The above inquiry commands only display information about jobs submitted by 
the node issuing the command. The :nodify commands only modify jobs sub- 
mitted by the node and userid/remote 1d issuing the command. 


The installation can provide a user exit (IATUX35) which accepts other com- 
mands, or places additional restrictions on the commands listed above. This user 
exit replaces the JES3 standard validation/authorization of the command. 


Only the following class “G” commands can be sent to RSCS from another node: 


¥ Comment for the RSCS operator’s console 


CMD Forward command to a remote system for execution. 

CPQUERY Request status information from CP. 

MSG Send a console message to a local or remote system or user. 

QUERY Request system information about a link, file or the system in 
general. 


Chapter 3. Operator's View of NJE 3-33 


In addition, the following commands can be used to control a file if the file came 
from the node which is sending the command: 


CHANGE Alter the attributes of a file. 

FLUSH Discontinue processing of an active file on a link. 
PURGE Remove inactive files from a link’s queue. 
TRANSFER Change the destination of a file. 


The remaining RSCS commands can only be issued by the RSCS console oper- 
ator or one with remote or link authorization. 


POWER Authorization 


POWER supports three levels of command authority, which can be specified on 
a node basis in the NDT. The authontty levels are as follows: 


NET This is the highest level that can be given to another node. It allows 
the node to perform many functions without being the owner of a 
job. 


JOB This is the default authority and allows remote operators to issue 
commands against jobs which onginated from, or are destined to that 
node. 


NOJOB This is the lowest level of authonzation and only allows certain 
display commands. 


Only the following commands can be issued by nodes having “NOJOB’ 
authority: 


PBRDCST Send a message to a remote user. 

PCANCEL Status Suppress status displays with PDISPLAY. 

PDISPLAY MSG Display “ALLUSERS”-type messages. 

PDISPLAY T Display time and date. 

PDISPLAY PNET Display network definition table. 

PINQUIRE Display status information about TP lines or logical units. 


In addition, the following commands can ve issued by users with “JOB” authonty 
if the job in question came from the node which is sending the command: 


PALTER Job Change attributes of a job. 

PCANCEL Job Flush a job in execution or that is printing. 
PDELETE Job Delete a job from the queue. 

PDISPLAY Job Display a job 

PDISPLAY A ___ Display active jobs. 

PHOLD Job Put a job in hold state. 

PRELEASE Job Release a job from hold state. 


See Chapter 4 of POWER Networking User's Guide for more details. 


4 The “owner” of a job may be changed by specifying a different node on the 
NOTIFY parameter. 


3-34 JES2 NJE 


Summary of Operator Commands 


Network Management 


Function 


Start Networking (SNA) 


Start Transmitters 
Start Receivers 
Drain Transmitters 


Drain Receivers 


Drain Lines 


Stop Networking 


Stop Networking 
diately 


Display 
nections 


Trace Line Problems 


The following tables provide a general reference of the operator commands avail- 


able on the various systems. 


Because of fundamental differences between the 


systems, commands in the same row may not be identical. Refer to the specific 
product operations guides listed above for details. 


JES2 


$SLNEnnn 


$SN,LNEnn 


$SLGNn 


$SN[,LNEnn],A = applid 


$SLn.JTm,Ln.STm 
$SLn.JRm,Ln.SRm 
$PLn.JTm,Ln.STm 


$PLn.JRm,Ln.SRm 


] SELNEnnn 
$CLNEnn 


$ELNEn,LNEm, 


$PLNEn,LNEm.,... 


$TNnnn ,A=auth 
,P=pw 
S=JR,.. ,H=JR 


$TR,ON,ID= +4+5 


Figure 3-6. Network Management Commands 


JES3 


*X,NJE,NAME = node 
+X SNA 


+S SNA,NODE= 


*F NJE,NAME= node, 
NOHOLD 


*S, line, RCV 


*F NJE,NAME= node, 
HOLD 


*S line, NORCV 


*C line, 


*F NJE,NAME= node, 
FORCE 


*C line 


Imme- $ELNEn,LNEm, *C line,I 


*F NJE,NAME= node, 
PATH = node2 


*S,line, LOG 


--- No available operator command 


5 Controlled by transmission algorithms. 


RSCS 
ENABLE cuu 
START node 


NETWORK 
START 


START node 


is: 


HOLD linkid 
DRAIN link 


STOP link 
FLUSH 


DISABLE/ENABLE 
cuu 


SHUTDOWN 
SHUTDOWN 
QUICK 

Q SYS LINKS 
Q SYS ROUTES 


S PNET,node,,line 


S PNET,node 


PACT 

PNET ,node,TRn 
PACT 

PNET ,node,RVn 

N PNET,node,TRn 


N PNET,node,RVn 
F PNET,node 


P PNET,node,EOJ 


P PNET ,node 
I ALL 


START link ... PLOAD PNET,ndt 
ROUTE dest to PLOAD PNET,ndt 
link 


DEFINE node PLOAD PNET,ndt 


CP TRACE linkid 


S PNET,node,,,, 
TRACE 
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File Control 


The following table shows the various operator commands that control jobs 
(SYSIN or SYSOUT, “files” to RSCS) on the various systems. Note that there 
are also global ($G..) commands for JES2 which can be used to control jobs on 
other nodes. See global commands in Figure 3-4 on page 3-24. 


JES2 JES3 (BSC) RSCS POWER 


Display Network Queues $DQ,Q = XMT[node] *] AJD=NJESND QUERY link Q PDISPLAY XMT 
$DQ,R= *I U,Q=BDT (6) 
Reorder Network Queues $TJnnn,P = *F U,Q=BDT (6) ORDER link splid ... A XMT,job,PRI = 
$TOJnnn,P = 
Display Job Routing $DJnnn $TOJnnn *] J= Q FILE splid RSCS D RDR,job 
D LST,job 


Function 


Re-Route Jobs $RXEQ,D= *S NJEROUT.... TRAN link splid TO A XMT,job,sNODE= 
Re-Route Output $RALL,D = node *S NJEROUT.... TRAN link splid TO A XMT,job,NODE= 
$TOJnn,D = , 
Release Jobs and Output CH splid NOHOLD- ‘| R XMTI,job] 
Cancel Jobs and Output $CJnnn tPF I= PURGE splid C XMT{,job} 
$PJnnn 


Figure 3-7. File Control Commands 


Sending Commands and Messages 


The following commands are available to system operators to send commands 
and messages to other nodes. 


Function JES2 JES3 RSCS POWER 


Send Message to Another $DMNn,’msg’ MSG node.RSCS msg 
Node 

Send Message to Interactive Cf *Z,node.user,msg MSG node user msg 
User 

Send Command to Another $Nnnn;cmd CMD node cmd 
System 


Figure 3-8. Sending Commands and Messages 


6 SNA Queues only with MVS/BDT 
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This chapter addresses the end-user considerations for using the NJE facility. It 
is written primarily for the systems programmers. responsible for developing 
installation-specific documentation and guidelines for the end-users. 
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Prerequisite Publications 


MVS/Sb 


VM/RSCS 


VSE/POWER 
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JES2 NJE 


The following list 1s a minimum set for end-users of NJE systems. Where mul- 
tiple form numbers are referenced, ensure that you have the appropriate one for 
your installation. 


Also see Appendix C, “Bibliography” for a more complete list. 


MVS (JES2 and JES3) end users include TSO users, submittors of batch jobs 
through local or remote readers, recipients of output through local or remote 
printer or punches, and programs which use the internal reader facility or 
Process-SYSOUT subsystem interface. 


System operators and RJE operators could be viewed as “end users”, but not in 
this publication. See Chapter 3, ‘“Operator’s View of NJE” for their view. 


MVS JCL User's Guide, GC28-1349 (Ver. 1) or GC28-1351 (Ver. 2) 
MVS JCL Reference, GC28-1350 (Ver. 1) or GC28-1352 (Ver. 2) 
TSO/E: User's Guide, SC28-1333 

TSO/E: Command Language Reference, SC28-1307 

TSO/E: Reference Summary, SX28-0015 


MVS end users may also include CICS (DISOSS), WYLBUR or other time- 
sharing users, but they are not discussed in this publication. 


VM end users include CMS users and other virtual machines run under control 
of VM/370 which uses RSCS Networking to communicate with other NJE sites. 


VM/SP: CMS User's Guide, SC19-6210 

VM/SP: CP Command Reference for General Users, SC19-6211 
RSCS Networking Operation and Use, SH24-5058 

RSCS Reference Summary, SX24-5135 


PROFS users on VM may also use NJE facilities, but are not covered in this 
publication. 


VSE end users include ICCF users and anyone submitting batch jobs through 
local or remote readers, or from other partitions in the VSE system. 


e VSE/POWER Networking User's Guide, SC33-6140 
e VSE/ICCF Terminal User's Guide, SC33-6204 
e VSE/ICCF Reference Summary, GX33-9011 


NJE Facilities 


Unit of Transmission 


Job Routing 


In NJE, the unit of transmission is a “job”, or everything between a Network Job 
Header and a Network Job Trailer record. For jobs being transmitted to another 
node for execution, it is a SYSIN job with associated JCL and SYSIN data. For 
job output, it is one or more SYSOUT data sets, all from the same job exe- 
cution. 


The following diagram illustrates the format of logical records in an NJE job 
transmission. 


SYSIN Job SYSOUT Job 
Stream Stream 


JOB 
HEADER 


J 
HEADER 


DATA SET 
HEADER 


JOB 
TRAILER 


DATA SET 
HEADER 


SYSOUT 
Data Set 


JOB 
TRAILER 


Figure 4-1. Job Stream Transmission Format 


SYSIN Jobs may be routed for execution at a remote node. There is no need for 
the user to know where the node is connected, how the network is configured, or 
if there is an available path to that node. 


See “Job Transmission” on page 4-5 for specific discussions on routing jobs in 
an NJE network. 
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Output Distribution 


SYSOUT data sets may be routed to any node in the network, and to any 
remote workstations or interactive users connected to those nodes. 


See “Output Distnbution” on page 4-17 for specifics. 
Message and Command Transmission 


NJE protocols provide for messages and commands to be transmitted between 
interactive users and operators at any node in an NJE network. They are sent as 
Nodal Message Records (NMRs), which are not generally spooled at interme- 
diate nodes, but get passed through the host without being stored on the spool. 
The facilities available to send and receive commands and messages differ greatly 
depending on the system and on the end users involved. 


See “Message and Command Transmission” on page 4-31 for specifics. 
File Transmission 


Although NJE is primarily used for transmitting spool files, many users need to 
also transmit bulk data such as OS Data Sets. There are basically two different 
ways to send bulk data: by using NJE, and by using a mechanism external to 
NJE. The NJE approach usually involves a utility or program at the sending and 
receiving end to transform the bulk data into and out of spool file format. The 
other mechanisms do not use the subsystem’s spooling system but communicate 
directly with another copy of itself through a separate BSC link or SNA session. 


See ‘File Transmission” on page 4-39 for specifics. 
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Job Transmission 


SYSIN Jobs may be routed for execution at a remote node. For guest operating 
systems running under VM/370, a destination of the format “Node.Userid” is per- 
mitted. There is no need for the user to know where the node is connected, how 
the network is configured, or if there is an available path to that node. 


The user must: 


e be familiar with the control statements on both the submitting (ongin) 
system and the execution (destination) system, 


e be able to package the SYSIN stream and tell the orgin system where to 
send the job for execution, 


e use the job control language (i.e., JCL and JECL) and standards of the exe- 
cution node, and 


® be aware of the resources required to run the job. 
In addition, NJE systems notify the end-user at various points of job trans- 


mission and execution. These vary from system to system. See ‘Notification 
and Tracking” on page 4-35 for details. 


Job Submission - JES2 


Explicit Routing 


Jobs submitted on a JES2 system can be sent to other nodes for execution. The 
execution node can be identified by several mechanisms: 


[*ROUTE XEQ or |*XEQ: The user may code a /®ROUTE XEQ or /®XEQ 
JES2 control statement (they are functionally identical) in the job stream. 


/fabe JOB xxxxx Cusec at origin and execution nodes) 
7*¥ROUTE XEQ nodename 
//STEP1 EXEC PGM=... 


Figure 4-2. JES2 /*ROUTE XEQ Statement. Routing a Job for Execution 


The job stream is scanned at the submitting JES2 node. See “Order Dependen- 
cies of JES2 Control Cards” on page 4-6 for JECL scanning details. 


[*XMIT: The user may code a /®XMIT JES2 control statement in the job 
stream. 
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//abc JOB xxxxx Cused at origin node only) 
/*¥XMIT nodename DLM=$$ 

S/4XYZ JOB vyyyyy Cused at execution node only) 
//STEP1L EXEC PGMe=... 


$$. 


Figure 4-3. JES2 /*XMIT Statement 


The job stream is not scanned beyond the 7*XMIT statement at the submitting 
JES2 node. All of the following card mages, up to but not including the delim- 
iter, are sent without any verification, syntax checking or any other validation. 
Any passwords or other sensitive data within that stream are not removed or 
encrypted. 


If submitted via TSO, TSO/Extensions (TSO/E) must be installed. Otherwise, 
unpredictable results will occur. 


If the job executes at another JES2 node, the job name will be changed to “xyz”, 
but if it executes at a JES3 node, the job name “abc” will be kept (in the 
Network Job Header). 


Note that there are no commas on the /*¥XMIT statement. (Before the fix for 
APAR OZ74692, a comma was crroncously accepted between the nodename and 
the DLM parameter.) 


Default Routing 


If not specified by the mechanisms above, the input device may have a default 
execution node associated with it. This can be specified on the JES2 
READERnn or Rnnn.RDm initialization statement. If not specified, the default 
execution node is obviously the node on which itt 1s submitted. (JES2 internal 
readers, however, cannot have a default execution node.) 


Job Re- Routing 


The operator can also sct or change the routing of a job. Sce “Re-Routing Jobs 
and SYSOUT” on page 3-22 for details. 


In addition, the systems programmer, through installation exits, can also set or 
change the routing of a job. See “Installation Exits and Modifications” on 
page 2-39 for details. 


Control Card Considerations 


Order Dependencies of JES2 Control Cards: JES2 control cards are order- 
dependent relative to the 7*ROUTE XEQ (same as “®XEQ) control statement. In 
general, if they are placed before a “ROUTE XEQ statement, they will be proc- 
essed on both the input and execution node. If placed before a /*%XMIT state- 
ment, they will be processed only on the input node. If placed after a /®ROUTE 
XEQ or “®XMIT statement, they are processed only on the execution node. 
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The following JES2 control] statements deserve special mention: 


/SRNETACCT 


If placed before the 7*ROUTE XEQ or /¥®XMIT statement, the network 
account number is carricd with the job. If placed after the 7*ROUTE XEQ or 
/¥*XMIT statement, it 1s ignored. 


S*NOTIFY 


If placed before the “ROUTE XEQ or /®XMIT statement, notifications are 
directed accordingly throughout the life of this job. If placed after the 
/*ROUTE XEQ or /¥XMIT statement, notifications are directed accordingly 
only after the job has been read on the execution node. See “Notification 
and Tracking” on page 4-35 and “Notification and Tracking” on page 4-35 
for details on notifications. 


/¥SETUP 


The SETUP statement should follow any /*ROUTE XEQ or /¥XMIT state- 
ment to keep it from being processed on the input node. 


/*PRIORITY 


If placed before the JOB statement routed with a “ROUTE XEQ statement, 
the pnionty is honored throughout the life of the job (according to the 
PRTYJECL parameter on the JOBDEF JES2 initialization statement). If 
placed after an 7*XMIT statement, it must immediately precede the second 
JOB statement, and doesn’t take effect until the job reaches the execution 
node. If placed before the first JOB statement preceding an /%XMIT state- 
ment, it becomes the job’s pnonity throughout the life of the job. 


User-defined control statements 


Any JECL statement placed before the /7*ROUTE XEQ or /¥®XMIT state- 
ments which 1s not acceptable at the input node will cause the job to fail. 
Any JECL statement placed after the 7XROUTE XEQ statement (acceptable 
or not at the input node) 1s transmitted with the job. Any card image what- 
soever placed after the /%XMIT statement (except a delimiter) is transmitted 
with the job. 


For more details, see the MVS/370 JCL manuals, GC28-1349 and GC28-1350 or 
the MVS/XA JCL manuals, GC28-1351 and GC28- 1352. 


Internal Reader Control Cards: Internal reader control statements (/%EOF, 
/*DEL, /XPURGE and /¥SCAN) take effect at the submitting node, but are not 
transmitted to the execution node. In the case of 7* PURGE, any output is purged 


and not sent to the job’s print destination. For /*DEL, the job output is sent to 


the job’s print destination. 
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Routing Jobs to a VM Guest-ID 


Job Attributes 


Network Account Number 


JOB Password 
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JES2 NJE 


NJE may be used to route jobs to a guest operating system on a VM/RSCS 
node, even if the guest is not a node in the NJE network. It may receive jobs by 
having it’s virtual reader spooled to RSCS. 


Of the above mechanisms to route a job for execution, the “®XMIT, /%XEQ and 
/RROUTE XEQ control statements permit a “nodename.vmguestid” to be speci- 
fied. In this case “vmguestid” is the name of a guest machine running under VM 
on the “nodename” specified. Operator commands and default reader routing 
only allow a node to be specified, and not a vmguestid. As the target execution 
node, JES2 ignores “vmguestid”, which is carried in the NJHGXEQU field in the 
job header. 


Operator Rerouting: The JES2 operator may reroute a job to a different 
node-id, but not to a VM guest-id. 


Routing to a Specific System-ID: In order to route a job to a particular 
system-id in a JES2 multi-access spool complex, either SYSAFF= (affinity) 
must be coded on the /%JOBPARM statement, or a job class structure must be 
used to control which system executes the job. 


Most of the job attributes are preserved in the network job header (NJH) control 
block. The NJH is transmitted with the job throughout its life in the network. 
This is one of the significant differences between NJE and remote job entry, 
because an NJE network keeps track of all the job-related parameters through 
eventual output distribution. 


The following job attributes deserve special mention: 


Only JES2 and JES3 support this field. 


JES2 will use the local account number for the network account number if there 
is no /¥NETACCT statement present and no translation due to JES2 NETACCT 
initialization statements.! 


For security reasons, the password is taken off the job statement at the ongin 
node (replaced with eight blanks) and transmitted in the network job header. 


The userid and groupid are placed in the JES2 section of the job header for spool 
offload operations, but zeroed out for NJE transmissions.’ At the execution node, 
the job is forced through validation again if it came from another node regardless 
of the presence of these fields. (See APAR OY04615.) 


I Fixed with APAR 0260994 


2 Function added with APAR OZ81051. 


Submitting Userid 


Job Priority 


User verification for NJE jobs should normally be done at the execution node. 
However, RACK authorization checking occurs at the ongin or execution node 
as follows: 


e Jobs sent with the ROUTE XEQ (or /%XEQ) statement are verified at the 
execution node only. 


e Jobs sent with the “*XMIT statement have their first JOB statement verified 
at the origin (submitting) node, and their second JOB statement verified at 
the execution node. (Authorization information is not propagated from the 
first JOB statement to the second.) 


See also “User Identification and Verification” on page 2-13. 


The name of the user submitting the job is saved in the job header, and is used 
for sending notification messages and for returning output from the job’s exe- 
cution. The use of NOTIFY may change the user and node’s ongin identifica- 
tion. 


See “Notification and Tracking” on page 4-35 for more information about notifi- 
cation. 


A JES2 7*PRIORITY statement may be submitted with a job. If the job is sub- 
mitted on a JES2 node and 1s placed before a /7%XMIT statement, the /*PRI- 
ORITY statement is commented out and the pnority is updated in the job header 
before the job is transmitted to another node. If it comes after a /%XMIT state- 
ment, it is ignored by JES2 on the execution node unless it immediately follows a 
/¥*XMIT statement and precedes the second JOB statement.’ 


If the /*XPRIORITY statement immediately follows a /%*XMIT statement, it is 
passed onto the execution node and processed according to the specification of 
the PRTYJECL parameter on the JOBDEF initialization statement at the exe- 
cution node. 


If the 7X PRIORITY statement is not present, or if JES2 ignores it, the job pn- 
onity is determined by: 


1. The PRTY parameter on the JOB statement (according to the specification of 
the PRTYJOB parameter on the JOBDEF initialization statement at the exe- 


cution node), or 


2. ‘The estimated execution time as specified on the /%JOBPARM statement, or 
the accounting information on the JOB statement, or 


3. An installation-defined default. 


3 Fixed with APAR 0265792. 
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Jobid Assignment 


Job Transparency 
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JES2 NJE 


For a detailed discussion on “JES2 Job Scheduling Pnonity’”, see the section by 
the same name in JES2 Initialization and Tuning. 


The JES2 jobid is a number that is assigned when a job first enters the system. 
This number is unique within a JES2 system. The job header always contains the 
onginal (input system’s) jobid for the life of the job. 


When a job is transmitted from one system to another, the receiving system 
attempts to assign the onginal jobid (from the job header) to the job that is being 
received. If this number is currently in use on the receiving system, a jobid is 
assigned as if the job were being read in locally. A different jobid is also assigned 
if a part of the original job is already on the receiving system, as may occur with 
spin data sets. The newly-assigned jobid is not transmitted in the job header, 
only the onginal jobid. 


Non-MVS Job Streams: A JES2 intermediate node does not scan any job which 
is not destined for execution on that node. The /%XMIT statement allows the 
user to submit non-MVS jobs for network transmission. All JES2 syntax scan- 
ning stops after an /%XMIT statement is encountered within a job at the ongin 
node. Only the data after the “%XMIT statement (and before a specified delim- 
iter) is transmitted across the network. Note that a valid MVS JOB statement 
must precede the “*XMIT statement, when submitted on a JES2 system. 


The jobname placed in the job header of an “XMIT” job is the name from the 
preceding MVS JOB statement. If this name is blanks, JES2 transmits a blank 
jobname in the job header. All relevant job header information (such as pnority 
and accounting information) is taken from the preceding JOB statement. 


Multiple Jobs Between a Header and a Trailer: If JES2 encounters more than 
one job between a job header and trailer, the job(s) will be flushed with the 
$HASP110 message.* 


Errors in JES2 JECL statements: If 1882 encounters an error in JES2 control 
statements, the remaining records 1n the job are skipped and the job is queued for 
output with an error message.° 


Record Lengths Greater than 80 Bytes: JES2 will store and forward job streams 
which contain data with a logical record length greater than 80 bytes.® 


4 Fixed with APAR 02793366. 
s Fixed with APAR OZ51862. 


6 Fixed with APARs 0288264 and OY02269. 


Additional Job Header Sections: As an intermediate node, JES2 will add the 
JES2 and job scheduling sections to the end of the job header if that header does 
not already contain those sections. JES2 also adds the accounting section to the 
job trailer during intermediate node processing. This should be transparent to 
JES2 and other systems and should not affect the processing of the job. 
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Job Submission from Other Systems 


Job Submission - JES3 


Explicit Routing: Jobs submitted at a JES3 node are sent to other nodes for exe- 
cution by using either the //®ROUTE XEQ or “/ XMITcontrol statement. The 
following JCL stream 1s an example: 


//abe JOB xxxxx first job statement 
S/¥*¥NETACCT  .... Coptional ) 

//¥®ROUTE XEQ nodename 

/7XYZ JOB yvyyyy second job statement 


47 


Figure 4-4. JES3 Job Example for Transmission 


The first job statement and the NETACCT and ROUTE XEQ statements are 
stripped off at the submitting node; what is transmitted is the second job state- 
ment and whatever follows up to the next job statement or end-of-file. This 


places the following restrictions on the user who wants to submit jobs from 
JES3: 


e Only one job at a time can be submitted for execution elsewhere. 
e Jobs must begin with a valid MVS JOB statement. 


e Users submitting jobs from TSO must code “NJB” in place of “JOB” on the 
second JOB statement. Otherwise, the second job statement will signal the 
beginning of a new job to TSO submit. 


Note that if the job executes at another JES3 node, the job name “abc” will be 
kept, but if it executes at a JES2 node, the job name will be changed to “xyz” (in 
the Network Job Header). 


To POWER Nedes: Because JES3 requires that the first card after the 
//*ROUTE statement be a valid OS JOB statement, the above example cannot be 
used to transmit jobs to POWER. With the SNA/NJE enhancement, JES3 sup- 
ports the 77 XMIT JCL statement which eliminates several limitations present 
with the /7*ROUTE XEQ statement. See the latest /CL Reference for details and 
examples. 


Without the SNA/NJE feature, see the VSE/POWER Networking User's Guide 
for an example using IEBPTPCH to accomplish the sending of a job from JES3 
to POWER. 


Operator Re-Routing: With the SNA/NJE enhancement feature, jobs (SYSIN) 
may be re-routed to another node. Previous versions of JES3 did not allow this. 
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System Qualifier on JES3: TSO users may be attached to any system in the 
complex and may submit network jobs and receive status and notify messages. 
The system qualifier in the job header is used to indicate to which system in the 
complex the user belongs. When a TSO user submits a job, a value is placed in 
the job header qualifier field NJHGORGQ. Other nodes may place this value in 
the NMRTOQUL field in the NMR for status or notify messages. 


The value which is used as the qualifier is a number from 1 to 8, which corre- 
sponds to the relative position of the Main Processor Control table (MPC) in the 
MPC chain for the appropniate system. 


Multiple Jobs between Headers: Unlike JES2, JES3 accepts multiple jobs in a 
job transmission (i.e., between the job header and job trailer). 


Record Lengths Greater than 80 Bytes: JES3 does not support SYSIN 


jobstreams or data greater than 80 bytes. The SYSIN data records will be trun- 
cated to 80 bytes. 
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Job Submission - VM 


A CMS user uses the TAG, SPOOL and PUNCH commands to send a job to 
another node as follows: 


TAG DEVICE PUNCH node-id JOB 


SPOOL PUNCH rscs-id 
PUNCH filename filetype filemode CNOHEADER) 


Figure 4-5. CMS Commands for Job Submission 


In the above example, ‘node-id’ is the name of the execution node and ‘rscs-1d’ is 
the name of the RSCS virtual machine on the submitting node. 


The job will be sent by RSCS with the job-name of “RSCSnnnn” where nnnn is 
the spool file id. JES2 changes the job-name to. the name in the 77 JOB state- 
ment. JES3 does not. 


Cautions 


Make sure that the punch device is tagged with the “JOB” attnbute. Otherwise 
the file arrives at the JES2 node in the punch queue instead of the input queue. 


Make sure that (NOHEADER), or (NOH for short, is specified. Otherwise a 
“READ” statement is put in front of the user’s job stream and the job will be 
rejected by JES2, a $HASP110 message issued, and the job will be sent back to 
the submitter. 


Send only one job at a time to JES2 (1.e., one for each PUNCH command) and 
do NOT spool the punch continuous. Otherwise the job will fail due to a JCL 
error. (It is alright to send multiple jobs in a file to JES3 Networking.) A cir- 
cumvention to this is to write a “smart” CMS EXEC which scans for multiple 
// JOB statements and punches each job as a separate file to RSCS. See “Sub- 
mitting Multiple JES2 Jobs from a Single CMS File” on page B-16 for details. 


Only 80-character records could be sent in SYSIN jobs with RSCS Version 1.3. 
This restnction is not longer true .. ‘h RSCS Version 2 which can send 
jobstreams containing records up to 255 bytes long. 


Jobid Assignment 


The VM Spool file ID is equivalent to the Jobid in other systems. No attempt is 
made by VM/RSCS to maintain the same spool file ID when it receives a file. 
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Job Submission - VSE/POWER 


For job routing, POWER supports a new parameter “X DEST” on the JOB state- 
ment. The format is® $$ JOB ...»XDEST=nodeid. This mechanism also 
allows a job to be routed to a VM _ usend by specifying the form 
“XDEST=(nodeid, userid)”. 


For more details, see the following references: 


e Section 4.2 in VSE/POWER Version 2 Networking Design Guide 
(GG24- 1570-0) 


e Chapter 4in VSE/POWER Networking User's Guide (SC33-6140) 
¢ Chapter 41in VSE/POWER Installation and Operations Guide (SH12-5329) 


Jobid Assignment: In POWER, the JOBID is a combination of Job Name and 
Job Number. The POWER job number is a halfword binary number assigned 
by POWER when the job first enters the system. This number may not be 
unique within the POWER system. POWER uses the job name as the primary 
identifier for all system control, and the job number as a secondary identifier. 


When POWER receives a job, a new (local) job number is assigned. However, 
POWER retains the orginal job number in the job header which is preserved in 
any further transmissions. The same is true for job output with the exception of 
segmented (in VSE terms) or spun off output (in MVS terms). In such a case, all 
segments will get the onginal job number in order to group all segments together 
regardless of when they arrived and to make queue manipulation easier. The job 
name is never changed. 


Chapter 4. End-User’s View of NJE 4-15 


Execution Node Requirements 
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In general, the user should be aware of the execution environment to which he 
sends any jobs for execution. 


User Access Authority 

If there is an access control facility like RACF, the user as identified on the 
JOB statement or in the job header must be defined at the execution node 
and the proper password supplied. 

Account Numbers 

Installations which use the JES-compatible 4-character account numbers may 
wish to use the translation services provided by JES2 through the NETACCT 
initialization statements or the “®NETACCT control statement. This allows a 
mapping from one set of local account numbers to another. 


Initiator classes 


The user (JCL coder or programmer) should be aware of what classes are 
appropniate at the execution node. 


Job Execution Order 

Jobs may get out of order during transmission. Once the jobs arrive at the 
executing system, any relationship between the jobs (e.g., order of execution) 
must be controlled by facilities available at that system. 

Procedure Libraries 

All jobs are converted/interpreted on the execution node. Commonly used 
procedures may need to be copied to other systems for use by a larger set of 
users. 


Unit Names 


Standardized esoteric names across the network or generic names (e.g., 
UNIT = 3400-6) must be used. 


Program libraries 
Data Sets 


Catalogs 


Any other local standards enforced by IBM or user code (e.g., exits) must also be 
observed at the execution node. 


Output Distribution 


SYSOUT data sets can be routed to any node in the network, and to remote 
workstations or interactive users connected to those nodes. 


When routing output to other NJE nodes, the user must be familiar with the des- 
tination names and control cards to route it there. The user must also be familiar 
with the output classes, printer characteristics and output standards on the other 
nodes. 


The end-user is notified at certain points of output transmission. These vary 
from system to system. See “Notification and Tracking” on page 4-35 for 
details. 


In addition to this section, also see ‘File Transmission” on page 4-39 for other 
ways of distributing output. 


Unit of Output Transmission: In NJE, a unit of transmission is defined as being 
everything between a Job Header and a Job Trailer record. It may consist of 
several Data Sets with different characteristics or destinations. 


Two-Level Routing: In NJE, SYSOUT data sets are routed first to a node, and 
optionally, to a user or remote workstation on that node. 


Most MVS interfaces and control blocks, such as the SSOB have only a single 
8-byte field for destination name. For this reason, the external writer name is 
often used to identify the userid as a second level routing specification. 


Three-Level Routing: Yo accommodate a userid on a remote terminal, or a user 


of an interactive subsystem such as CICS, use private protocols. This is often 
done by placing the userid in the first data record of the file to be transferred. 
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Routing Output - JES2 


Explicit Routing 
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Jobs executed under JES2 can have their output sent to other nodes for distrib- 
ution. The output node may be identified by several mechanisms: 


There are a number of ways to route output to another node. Below 1s an over- 
view of the different statements. Refer to the JCL Manuals for more specific 
information. 


[*ROUTE Statement: Code a 7®XROUTE PRINT or “®ROUTE PUNCH control 
card in the job stream to route all SYSOUT data sets for the job. This overndes 
any default routing for the reader (see below) and becomes the default routing for 
all print or punch SYSOUT data sets in the job. (The routing of individual 
SYSOUT data sets can be overridden if specified on a DD or OUTPUT JCL state- 
ment or on a “OUTPUT JES2 control statement.) Only one destination can be 
specified on the /%ROUTE statement. 


The /%ROUTE statement also establishes ‘job ownership’ which is important in 
JES2 command authorization-checking. (See the discussion on remote command 
authorization in “JES2 Authorization” on page 3-33.) 


DD JCL Statement: The user may code DEST on the 77 DD SYSOUT JCL 
statement. If the form (nodename,userid) is used, the writer-name 
cannot be specified. 


OUTPUT JCL Statement: The user may code DEST on the 77 OUTPUT JCL 
statement. Only one destination can be specified, but multiple (up to 128) 
4/7 QUTPUT JCL statements can be provided for the same set of output data sets, 
each with a different destination. 


[*OUTPUT Statement: The user may code up to four destinations in the DEST 
parameter on the 7XOUTPUT JES2 control statement. Users should be encour- 
aged to use the “7/7 OUTPUT statement instead of 7X OUTPUT. 


TSO OUTPUT: Use the DEST parameter the TSO OUTPUT command to 
specify an output node, or an RJE workstation on this node, but not both. (See 
“TSO/E Interactive Data Transmission Facility” on page 4-40 for a discussion 
about a facility to send files to another TSO user.) 


Dynamic Allocation: SVC 99 (dynamic allocation) may specify a destination of 
another node or an RJE station on this node in the DALSUSER text unit, and 
optionally a user-id in the DALUSRID text unit. If DALSUSER is an actual 
JES2 remote name (e.g., Rnnnn), then DALUSRID 1s ignored. See MVS Job 
Management GC28-1303 or MVS/XA System Macros and Facilities, Volume | 
GC28-1150 for details. 


With TSO/E Release 3, the ALLOCATE command supports 2-level (nodeid.userid) 
destinations. 


Internal Reader Job Output Routing: If the job is submitted through an internal 
reader, the default print and punch destination for the job(s) may be specified by 
the DEST parameter on the “7 DD SYSOUT JCL statement for the internal 
reader. 


Special Local Routing: JES2 only supports special local routing on the “local” 
node. These “Unnnn” routecodes are not supported in conjunction with nodal 
routecodes. Symbolic destinations can be defined on the target node to translate 
the routing of output to special local route codes with the DESTID initialization 
statement. See the example below and “Symbolic Destinations” on page 4-21. 


At the Origin or Execution Node, code the following on an OUTPUT statement: 


// OUTPUT DEST=TARGNODE.MYPRINTR 


At TARGNODE, have a symbolic destination defined in JES2 
initialization parameters: 


DESTID NAME=MYPRINTR, DEST=U23 


Multiple Copies or Destinations: Using NJE, a single copy of a SYSOUT data 
set may be sent with multiple data set headers to optimize transmission of the 
same data sets to multiple destinations. (Each destination can also have different 
SYSOUT characteristics.) 


The following diagrams illustrate multiple data set headers for a single data set for 
“fan-out” and “drop-off”. In this example, the same SYSPRINT SYSOUT data 
set is sent to nodes 2, 3 and 4. This can be accomplished with either of the fol- 
lowing sets of JCL/JECL statements: 


7RXOUTPUT code DEST=(N2,N3,N4) 
//SYSPRINT DD SYSOUT=CA, code) : 


= ef = 
//QUTIN2 OUTPUT DEST=N2 
//OUTNS OUTPUT DEST=N3 


//OUTNG OUTPUT DEST I4 
//SYSPRINT DD SYSOUT=A, OUTPUT=C¥.OUTN2, *.QUTN3S,*.OUTNG) 


See the following diagram. 
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Figure 4-6. Output Fan-Out - JES2 


Operator Control: ‘The system operators may also set or change the output des- 
tination of SYSOUT data sets. See ‘“Re-Routing Jobs and SYSOUT” on 
page 3-22 for details. 


If not explicitly specified by the user, output is routed according to the following 
rules: 


Reader Defaults: If the job is being submitted through a local or RJE reader, 
the default print and punch routing are determined by the PRNODE, PRDEST, 
PUNODE, and PUDEST parameters on the READERnn and Rnnnn.RDm 
JES2 initialization statements. (Internal readers cannot have default print and 
punch routing; refer to ‘Internal Reader Job Output Routing” on page 4-19.) 


If not specified by any of the above-mentioned means, the default output distrib- 
ution is the submitting (ongin) node. If submitted from a remote workstation, 
then the default output destination is the remote on that node. If submitted from 
a userid on a VM node, however, the default destination routing for output is the 
system printer on the origin (submitter’s) node. 


If a node is not explicitly coded in the DEST parameter, the default node 1s the 
origin, and the output gets routed back to the submitter’s node. If 
“DEST =RMTnnn” 1s specified in the JCL, the remote workstation is assumed 
to be on the ongin node. If “DEST = LOCAL” 1s specified in the JCL, the desti- 
nation is assumed to be the origin node. 


Symbolic Destinations 


JES2 handles symbolic destination names that are defined by the installation as 
‘DESTIDs’, 1.e., aliases for node or node/remote names. For example, an instal- 
lation can define 


DESTID NAME=DESTNAME, DEST=N21R17 
which equates ‘DESTNAME’ with a routing of node 21, remote 17. 


A DESTID can be specified anywhere in JCL that a destination name or userid 
can be. For example, DEST=destid or DEST=nodename. destid are allowed 
on //OUTPUT or /XOUTPUT, or simply ‘destid’ or ‘nodename.destid’ on 
/*ROUTE PRINT/PUNCH. (Destids can also be used on /%®XMIT or 7¥ROUTE 
XEQ JCL.) 


At the ongin node, JES2 will attempt to convert stand-alone destids (1.e., the 
DEST=destid form) BEFORE queueing for transmission. The converted desti- 
nation node or node/remote 1s used as the final destination. JES2 will NOT 
convert a destid within a ‘nodename.destid’ specification, as it assumes it to be a 
userid. It will pass the destid as is in the NDHGRMT field of the data set 
header. (It is possible to code DEST=destid1.destid2, in which case destid] 
will be converted before transmission and destid2 will get stuffed as is into 
NDHGRMT.) 


Any conversion of destids is always done based on the installation definitions for 
destids at the node of conversion. 


At the destination node, JES2 will attempt to ‘interpret’ NDHGRMT to deter- 
mine the routing of the data set. (NDHGNODE 1s used to determine the desti- 
nation node.) If NDHGRMT is of the form “Rmm/’ OR matches a destid which 
is an alias for ‘Rmm’, then the data set will be routed for remote mm. If 
NDHGRMT is of the form “NnnRmm/’ OR matches a destid which converts to 
‘NnnRmm’, then the data set will be routed for remote mm ONLY IF Nnn 
equals the destination node, otherwise the data set is queued for local printing (or 
to be picked up by a TSO user if NDHGXWTR is also set matching 
NDHGRMT). Note that the destids used for comparison in this case are those 
defined at the destination node. As mentioned above, it is possible for 
NDHGRMT to contain a destid by specification of DEST = nodename.destid in 
the origin job’s JCL. 
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Routing Output from Other Systems 


Routing Output - JES3 


Jobs executed under JES3 may have their output sent to other nodes for distnb- 
ution. The output node can be identified by several mechanisms: 


Explicit Routing: The user may code DEST on the 77 DD JCL statement, or 
on the 77 OUTPUT JCL statement. Only one destination can be specified, but 
multiple 77 OUTPUT JCL statements (up to 128) can be provided for the same 
set of output data sets, each with a different destination. 


The user may code up to four destinations in the DEST parameter on the 
/7*FORMAT JES3 control statement. This will not work with held output. Use 
the 77 OUTPUT statement for held SYSOUT. 


The TSO OUTPUT command may use the DEST parameter to specify an output 
node. A remote terminal or user-id cannot be specified on another node. 


With TSO/E Release 3, the ALLOCATE command supports 2-level 
(nodeid.userid) destinations. 


Operator Routing: SYSOUT data sets which are on the transmission queue 
waiting to be transmitted can be re-routed to another node, another 
userid/remoteid on the same or a different node, or to the local node. 


Default Routing: In MVS/SP 1.3.1 and earlier, JES3 set the default output desti- 
nation to the execution node. Starting with JES3/1.3.4, the default output node 
is the node on which the job was submitted. 


Routing Output - VM 


Explicit Routing: ‘Yo send output to another node, a CMS user can use the TAG, 
SPOOL and PRINT or PUNCH commands similar to sending jobs (see above). 


TAG DEVICE PRT node-id user-id prty <options ... 


SPOOL PRT rscs-id CLASS c <options ... 
PRINT filename filetype filemode 


Figure 4-7. CMS Commands for Sending Output 


In the above example, ‘node-id’ is the name of the destination node and ‘rscs-id’ 
is the name of the RSCS virtual machine on the sending system. As part of the 
TAG command, most of the output characteristics can be specified with keyword 
parameters. Each CMS file is sent separately when multiple PRINT commands 
are issued with the same TAG and SPOOL specifications (as long as you do not 
spool your printer continuous.) 


Several of the <options ...>, such as FCB, FORM and FLASH can be spec- 


ified on both the TAG and SPOOL commands. See the RSCS Networking publi- 
cations for details. 
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To Interactive Users: The SENDFILE command may be used instead of the 
SPOOL, TAG and PRINT or PUNCH commands for simple transmissions with 
no special attributes. This form cannot be used to send output to a pminter or 
punch for the data must be reformatted with the RECEIVE command at the desti- 
nation. Also, the NOTE command may be used to send a “note” to another user. 
See also “VM File Transmission Facilities” on page 4-42 for other mechanisms. 


To MVS TSO Users: By using the wnter name (W=user-id) on the TAG 
command (in addition to the node-id and user-id), the file may be sent to a TSO 
user on a MVS node. 


Default Routing: If a job is submitted by a CMS user for execution on a JES2 
node and the output destination is not specified, the output will be returned to 
the submitting node, but not to the submitting user-id. The output will be 
printed by the VM system printer (or punch). If you want the output returned to 
the submitting user’s virtual reader, explicitly code the destination in the job’s 
JCL. 


Routing Output - POWER 


Explicit Routing: At the job level, POWER supports the LDEST (‘list” or 
“print” destination) and PDEST (“punch” destination) specifications on the JOB 
JECL (Job Entry Control Language) statement. The format 1s: 


* $$ JOB ...,LDEST=Cnodeid,userid),PDEST=(Cnodeid, userid) 


For print and punch segments of the job, the “DEST = (nodeid,userid)” may also 
be specified on the LST and PUN JECL statements. 


* $$ LST DEST=(€nodeid,userid) 
* $$ PUN DEST=(Cnodeid, userid) 


Default Routing: The default routing in VSE/POWER 1s always the point of 
origin unless overwntten by JOB parameters or explicitly by the DEST parameter 
in the * $$LST/PUN statement. The “point of origin” for an interactive user 
(ICCF) means that the output stays on spool with a “to” destination of the ICCF 
user id, so that the ICCF user can '~ok at it and later delete the output or re- 
route it for printing. 
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Output Transparency 


Output Attributes 


3800 Attributes 


FLASH 


BURST 


Lines per page 
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In general, all NJE nodes spool SYSOUT data in a transparent manner. The 
objective is to deliver the output, along with its attributes, from the source to the 
destination without any changes. However, the process of storing them on spool 
at execution and store-and-forward nodes involves some changes due to differ- 
ences in output types supported and spooling techniques. 


See the specific attributes below and Appendix B of N/E Formats and Protocols 
GG22-9373 for more details. 


The job output attributes are preserved in the network data set header (NDH) 
control block. The NDH is transmitted with the data set, and is another signif- 
icant difference between NJE and remote job entry, because a job network keeps 
track of all the output parameters through eventual output distribution. 


The following sections explain how each of the NJE products transmit output 
and any restrictions to the transparent handling of output data sets. 


RSCS (Version 2): The best way to onginate 3800 files from VM is to define a 
virtual 3800 printer before you issue the PRINT command. RSCS always turns 
on the OPTCD=J flag in this case. The user can force OPTCD=J for other 
virtual printer devices. 


When receiving 3800 print files at a VM node, any 3800-specific attributes, or a 
logical record length (in NDHGLREC) longer than 150 will cause the file to be 
spooled as a 3800 pnnt file. 


JES2 and JES3 use “NONE” to specify that no FLASHing is to be done on the 
3800, even if the pmnter is providing 2 default forms FLASH. RSCS and 
POWER do not currently understand the special value of “NONE”, and wait for 
an explicit FLASH named “NONE” before printing the output. 


JES2, JES3 and POWER may set and honor the BURST attribute. RSCS does 
not honor the flag as a print node, but supports it in the TAG command for 
other systems. 


JES2: The LINECT parameter on the /*OUTPUT card is used to control indi- 
vidual SYSOUT data sets. The value ts placed in, and retneved from, the field 
NDHGLNCT in the Network Data Set Header if the flag X’04’ NDHGFI1LC is 
set in NDHGFLGI. (JES3 does not use this field but lets it default to zero.) 


Data Set Hold 


Print vs. Punch Attribute 


Job Copies 


Writer-Name 


JES3: On the other hand, JES3 uses the OVFL=ONJ|OFF indicator (bit 
NDHGFIOV in NDHGFLGI in the data set header) to specify whether (ON) 
or not (OFF) to skip to channel one if a channel 12 is sensed in the pmnnter 
FCB.’ 


RSCS: Neither the above fields or flags are set or used by RSCS. 


POWER: Neither the above fields or flags are set by POWER, but the 
NDHGF IOV flag is used. 


JES2: Sce the “Held Output” discussion under “Receiving Output - MVS” on 
page 4-29. The X’40’ bit (NDHGFIHD) in the flag (NDHGFLGI) in the 
Network Data Set Header is used to indicate that the data set should be held at 
the destination. The output is not held until it reaches the destination node 
where it is held regardless of the SYSOUT class definitions at that node. 


JES3: JES3 sets the NDHGFI1HD flag bit at the execution node and honors it 
by putting output received with this bit on into a held SYSOUT class.® 


JES2 and JES3: On the execution node, JES2 sets the flags NDHGF2PR or 
NDHGF2PU depending whether the SYSOUT class attribute table for that class 
specifies print or punch respectively. For received files, the SYSOUT class is 
used to determine whether it is printed or punched. 


RSCS: For received files, this flag field is used to determine whether to send the 
output to a printer or punch device. 


POWER: This flag field is used to determine whether to send the output to a 
printer or punch device. 


JES2 is the only system which sets or uses the job copy count field 
(NJHGJCPY) in the job header. Therefore, if set on the JES2 node (on the 
/¥*% JOBPARM statement), multiple job copies will not be printed or punched on a 
non-JES2 node. 


In addition to its use for the name of an MVS external wniter, this field is also 
used by the TSO/E Interactive Data Transmission Facility RECEIVE command 
to get files from JES for a TSO user. It is set by both the TSO/E TRANSMIT 
command and the VM SENDFILE and NOTE commands. 


” See APAR OZ78140 (closed SUGG) for more information. 


8 Fixed with APAR 0276793. 
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See the JCL manuals for restrictions when using this field at the same time as 
destination userid. 


PAGEDEF and FORMDEF 


PAGE-Mode Data 
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PAGEDEF and FORMDEF names may be associated with the data, regardless 
of the PAGE or LINE mode of the data itself. 


Line mode data can have a 1- to 6-byte PAGEDEF or FORMDEF name associ- 
ated with it. Information in the PAGEDEF is used to format the data itself, 
while information in the FORMDEF is used to specify form characteristics, such 
as data origin on the page, or simplex/duplex or bin selection on the 3820. 


The minimum levels required to specify and print PAGEDEF and FORMDEF 
names for line data records are: 


JES2 SP/1.3.4 or 2.1.2 

JES3 SP/1.3.4 or 2.1.2 

VM/RSCS_ RSCS Version 2.2 and VM/SP Release 5 or VM/HPO Release 5° 
POWER Version 2.3 for specifying, Version 2.2 for printing 


The minimum levels required to store-and-forward PAGEDEF and FORMDEF 
names with line data records are: 


JES2 SP/1.3.3 or 2.1.1 

JES3 SP/1.3.3 or 2.1.1 

VM/RSCS__ RSCS Version 2.1 and VM/SP Release 4 or VM/HPO Release 4 
POWER Version 2.1 


Prior to these levels, the FCB parameter could be used to identify a 4-character 
PAGEDEF name. (In MVS, this could be an alias.) FORMDEFs, on the other 
hand, have no equivalent JCL parameter for line-mode printing. 


See “Networking Advanced Function Printing Data” on page B-7 and the dis- 
cussion following on PAGE-mode data for more details. 


Page-mode, or composed-text data such as GDDM or DCF output formatted for 
a PSF-controlled printer, contains variable-length spanned records beginning with 
a X°5A* character. 


The following minimum levels are required for the transmission of page mode 
data: 


JES2: SP/1.3.3 can store and forward page-mode data. SP/1.3.4 is required to 
originate or receive and print page mode data. 


9 The PSF command may be used to specify PAGEDEFs and FORMDEFs with in 
VM Release 4 using private protocols. 


JESNEWS 


JES3: SP/1.3.1 can store and forward page-mode data. SP/1.3.4 is required to 
originate or receive and print page mode data. 


RSCS: Version 2.1 can store and forward page-mode data. Version 2.2 1s 
required to originate or receive and print page mode data. 


The PSF command can be used to send a file to other NJE nodes for printing. 
Note the following restrictions with this command: 


e VM/PSF installed on Release 4 of VM/SP or VM/HPO can only send 
output to PSF on another VM node. 


e VM/PSF installed on Release 5 of VM/SP or VM/HPO can send output to 
other NJE nodes supporting AFP, but in-line resources can not be included 
unless the destination is PSF on another VM node. 


e RSCS Version 1.3 cannot send or receive page mode data. RSCS Version 
2.1 1s required to store and forward page-mode data. RSCS Version 2.2 is 
required to originate or receive and print page-mode data. 


e VM (VM/SP or VM/HPO) Release 5 is required to send or receive page 
mode data. 


See PSF User's Guide for VM $544-3512 for more information on the VM PSF 
command. 


POWER: VSE/POWER Version 2.2 can store and forward page-mode data. 
The same level is required to originate or receive and print page-mode data. 


See “Networking Advanced Function Printing Data” on page B-7. 


The JESNEWS data set printed by JES2 during hard-copy processing is not sent 
to other other nodes. It is only printed with job output on local or RJE printers 
attached to the node at which the JESNEWS is defined. 
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Output Node Requirements 
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Any destination used for SYSOUT processing must have the proper facilities to 
print, punch display or otherwise handle the output. 


Special Devices: Obviously, the appropnate output devices, such as card 
punches, page printers, diskette writers, microfiche printers, plotters, etc. must be 
available at the output node. 


SYSOUT Classes: If the SYSOUT classes are not standardized across the 
network (which can be very difficult) they must at least be coordinated and well 
publicized (especially dummy, held, and punch classes). These characteristics will 
be referenced (1.e., take effect) on the system to which the output is routed. 


Special Forms: Not only must the appropnate forms (paper stock) be available 
at the output location, but form numbers must also be coordinated. 


SYSIIMAGELIB: Define the required FCB, UCS, and character arrangement 
tables in the output node’s SYS1.JMAGELIB data set. Therefore, IEBIMAGE 
must be executed at the node where the output is printed. 


AFP Resources: ‘The required fonts, page segments, overlays and format defli- 
nitions must exist in the appropriate libraries at the output node. However, for 
DCF to properly script a document in APA mode, the DCFINDEX file to 
define the fonts are required as well as any imbedded page segments (unless the 
size is explicitly coded). 


In general, observe any local standards established by IBM code or user proce- 
dures on the output node. 


Receiving Output 


Receiving Output - MVS 


Notes (electronic mail) as well as SYSOUT files can be sent to interactive users. 
This section explains how they can be received. 


There are two ways a TSO user on JES2 or JES3 can receive output data sets, 
and a third way with SDSF. 


Held Output: The TSO OUTPUT command can be used to view, print or copy 
the output if the the jobname is equal to the receiving TSO userid (plus one 
character),!° and one of the following rules are met: 


1. HOLD= YES was specified on the SYSOUT data set. 


2. Output is in a held class and the MSGCLASS was also a held class according 
to the SYSOUT class attribute table at the execution node. 


3. (JES2 only) Output is in a held class and MSGHOLD= NO 1s specified on 
the OUTCLASS initialization parameter for that class at the execution node. 


The hold indicator is set (bit NHDGFIHD in NDHGFLGI in the data set 
header) by JES2 at the execution node and used at the destination node to hold 
the output. 


Transmitted Files; The RECEIVE command can be used to display “notes” or 
copy files to an MVS data set that were sent with the TSO/E Interactive Data 
Transmission Facility, or some equivalent function such as the CMS SENDFILE 
facility. See “TSO/E Interactive Data Transmission Facility” on page 4-40 for 
more details. 


JES2 Note: Although R, RM and RMT, followed by numerics are valid charac- 
ters to use for the beginning of a TSO usend, those users will not be able to 
receive any transmitted files or notes. If used and the SYSOUT is transmitted 
from another node, JES2 on the receiving node does not distinguish the difference 
between a userid or remote number."! 


SDSF Browse: If authonzed, a TSO user on JES2 can use SDSF to browse 
output on spool which is destined for that userid. 


10 See TSO exit IKJEF53 and JES3 exit IATUX30 for variations. 


il See APAR O2Z85780. 


Chapter 4. End-User’s View of NIE 4-29 


Receiving Output - RSCS 


Files sent to a CMS user are queued in that user’s virtual reader. They have the 
following file-name, file-type, and class based on their origin: 


FILENAME FILETYPE CLASS 
CMS SENDFILE original filename original filetype PUN A 
CMS NOTE “NOTE” PUN A 


Origin/Sender 


PROFS NOTE PUN A 
MVS Batch Job SYSIN PUN A 


MVS Batch Job SYSOUT OUTPUT’ SYSOUT 
class 


TSO/E TRANSMIT TSO userid “OUTPUT” PUN B 


SENDFILE/TRANSMIT ”“Acknowl” “edgment PUN A 
Acknowledgement 


Figure 4-8. Filename, Filetype and Class of RSCS Reader Files 


While still in the user’s virtual reader, they can be ‘peeked’ (viewed) or discarded 
with the RDRLIST command before they are received. 


Each spool file is usually stored on the user’s disk as a separate file. If several 
output data sets are contained in a single job output stream (i.e., between a job 
header and job trailer), RSCS will attempt to combine them into a single CMS 
file if the output attnbutes and logical record lengths are identical. 


If the SYSOUT data sets are read into a CMS user’s virtual reader and stored as 
a CMS fue (instead of printed by RSCS), all the output attributes are lost. 
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Message and Command Transmission 


Sending Messages 


MVS - TSO Users 


JES2 - Batch Users 


NJE protocols provide for messages and commands to be transmitted between 
interactive users and operators at any node in an NJE network. They are sent as 
Nodal Message Records (NMRs), which are not generally spooled at interme- 
diate nodes, but are passed through the host without being stored on the spool. 


Intermediate 


| SPOOL | 


Not 


oe 


Y 
| SYSoUT | 


The facilities available to send and receive commands and messages differ greatly 
depending on the system and on _ the end-users involved. See 
‘“(Command/Message Transparency” on page 3-31 for a discussion on how the 
various systems transmit messages and commands. 


TSO users cannot send messages or commands to other nodes or users on other 
nodes. The TSO SEND command only works for users on the same node. 


XMIT: With the TSO/E Interactive Data Transmission Facility, the TSO 
TRANSMIT (or XMIT) command can be used to transmit “notes” to users on 
the same computer system, or another system connected via NJE. These are 
actually sent as SYSOUT data sets. and not to be confused with a “message” 
which NJE systems transmit as Nodai Message Records (NMRs). 


Some installations have wntten TSO command processors and JES2 exits to 
provide a facility for TSO users to send messages to users on other nodes. See 
the SHARE JES2 MODS tape for an example (VMSG and EXITO0SA on 
TUCC.NETMODS). 


To send messages to users on other nodes, JES2 operator commands can be put 
in the job stream if the installation allows. 


To Users on JES2 Nodes: If the target node is JES2, the following job stream 
can be used as an example to submit commands through the internal reader. 
(This is not very elegant, but it gets the job done.) This will only work if the 
installation allows commands to be submitted through the internal reader. (Most 
installations do not allow this.) 
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CMS Users 
VSE 
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//AUTCH3S JOB (6363,D002), "'HUTCH' ,MSGCLASS=Q 
/7¥XEQ target—node 

// EXEC PGM=IEBGENER 

//SYSPRINT DD DUMMY 


//SYSIN DD DUMMY 

//SYSUT2 DD SYSOUT=CA, INTRDR) 

//SYSUT1 DD DATA, DLM=$$ 

eae iaene "'Good morning'!,USER=CHUTCH) ! 


To Operators on JES2 Nodes: The same technique can be used to send a 
message to a JES2 operator on another node. Either leave off the USER= 
parameter or use the JES2 $DM command. 


To send messages to users on other nodes, the CMS user can use the SMSG or 
TELL commands, or the NOTE facility. 


SMSG: The SMSG command must be directed through the RSCS virtual 
machine and used in conjunction with the MSG command as follows: 


SMSG rscs-id MSG node-id user-id message-text 
os gigs ee 


TELL user-id at node-id message-text 


What you're actually doing is sending the MSG command to the RSCS virtual 
machine, which then sends the message-text to user-id at node-id. The class 


G MSG command cannot be used directly because that form does not support a 
link or node identifier. 


TELL: The CMS TELL command (which actually uses the above form of the 
CP SMSG command) can also be used to send messages to users on other nodes. 


With RSCS Version 2.2, messages sent to another node will have only the 
NMRFLAGT (time-sharing user) and not the NURFLAGW (workstation) flag 
set. This way they are displayed by JEt. to TSO users. 


NOTE: The NOTE command can be used to transmit “notes” to users on the 
same computer system, or another system connected via NJE. These are actually 
sent as SYSOUT data sets (VM PUNCH files). It can use the NAMES fie for 
nicknames. 


VSE ICCF users can send messages to users on other nodes with the /CP 
command. 


Sending Commands 


MVS - TSO Users 


JES2 - Batch Users 


Sending commands to other systems is not generally supported for the end-user, 
although there are some “work-arounds” available. 


TSO users cannot directly send commands to another node without submitting a 
batch job (see below). 


The STATUS, CANCEL and OUTPUT commands only work with the local JES 
system. The TSO user will either have to wait for the job to return to his node, 
or ask the operator to use a system command to display or control the job on 
another node. 


The following jobstream is an example of a technique that can be used to send 
commands to another JES2 node, assuming the internal reader on the target node 
allows that level of command authority. (Most installations do not allow this.) 


//HUTCH 


JOB... 
target-—node-id 
EXEC PGM=IEBGENER 
//SYSPRINT DD DUMMY 
//SYSIN DD 


DUMMY 
SYSOUT=CA, INTRDR) 
DATA, DLM=$$ 


4/7 SYSUT2 DD 
S/SYSUTI DD 
7¥SDSPL,ALL 
Aa a A’ 


Figure 4-9. Jobstream to Send Commands to JES2 Node 


The responses to these commands are not returned to the TSO user, so the user 
must logon to the target system and use SDSF to examine the log (if so author- 
ized). 


To send commands to a_ secondary JES2 system, use the form 
7#SNS,"'tjes2-cmd" where the ”!” is set by the RDRCHAR parameter of the 
CONDEF initialization statement on the secondary subsystem. 


See “Sending Commands from JES2” on page 3-29 for system operator facilities 
for sending commands. 


Chapter 4. End-User’s View of NJE 4-33 


VM - CMS Users 


To send a command to another system, use the SMSG command to direct the 
RSCS machine to route it to the remote node. 


SMSG rscs-id CMD node-id command-text 
The “CMD” command is not available to general users. Therefore, it must be sent 
via a SMSG command to the RSCS virtual machine which will, in tum, send the 
command to the “node-id” requested. 


VSE/POWER - ICCF Users 


If they have the proper authonty, ICCF users can issue the /CP command to 
issue VSE/POWER commands. 
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Notification and Tracking 


JES2 


JES3 


As a SYSIN or SYSOUT job is routed through an NJE network, notification 
messages are sent to the ongin node and userid (or designate) at various points 
depending on the system type. The following sections list the notifications sent 
by each system. 


Once a job has left the submission node, the end-user cannot generally display 
the job’s status or control it. The end-user must place a telephone call or send a 
message to the system operator who can display or control jobs on remote nodes. 


SYSIN Jobs: When a job is first read in by JES2, the TSO userid for notifica- 
tion is stored in the job header if ’NOTIFY’ was specified on the JOB statement 
or a JECL /*NOTIFY statement was included in the job. The onginating node 
name is also stored in the job header, but can be overridden by the /®NOTIFY 
statement. 


JES2 sends notification messages at the following times dunng SYSIN job trans- 
mission and execution, assuming that NOTIFY was specified: 


e Job transmitted from its origin node for execution on another node 
($HASP526) 


e Job received at intermediate and execution nodes ($HASP122)!? 

e Job completes execution, is cancelled or terminated (SHASP 165) 

SYSOUT Jobs: When any of the job’s output data sets reach the destination 
node, the destination SYSOUT receiver issues a message (SHASP546) to the 
TSO userid specified in the job header. This notification message is sent to the 
job’s origin node, indicating where the job’s data sets were received. 

TSO Received Files: For files transmitted to him by TSO/E TRANSMIT or CMS 
SENDFILE, the user is notified of the arrival of those files if JES2 Exit 13 has 
been implemented accordingly. Sc “MVS File Transmission Facilities” on 


page 4-39 for details. 


TSO Commands: The TSO STATUS, CANCEL and OUTPUT commands are only 
operative if the job is on the same node as the TSO user. 


The following notifications are sent by JES3. 


12 Added for intermediate nodes with APAR OZ84814. See also OY04055. 
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RSCS 
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SYSIN Jobs: JES3 sends notification messages at the following times during 
SYSIN job transmission and execution if the job header contains a notify userid: 


e Job transmitted (forwarded) to another node, including intermediate nodes. 
(IAT9199) 


e Job received at the execution node (IAT9140) 
e There is no notification when the job completes execution, but the I[AT7090 
message is sent when output from the execution of the job is queued for 


transmission, which may be about the same time. 


With SNA (i.e., MVS/BDT), only the IAT9140 notification is sent. (Job arnves 
at execution node.) 


SYSOUT Jobs: JES3 sends notification messages during job output trans- 
mission: 


e Output queued for transmission at the execution node (IAT7090) 


e Output transmitted (forwarded) to another node, including intermediate 
nodes (IAT9199) 


¢ Output received at the destination (I[AT9141) 


With SNA (1.e., MVS/BDT), only the IAT9141 notification is sent. (Output 
arrives at the destination node.) 


TSO Received Files: \NWith JES3 exit IATUX42, TSO users may be notified with 


the IAT9154 message when files arrive for them from TSO/E TRANSMIT or 
CMS SENDFILE. 


RSCS sends notification messages to the sender at the following times during file 
transmissions: 


e File queued for transmission at the ongin node (DMTxxx101]) 


e File successfully transmitted on a link, including intermediate nodes. 
(DMT xxx147I) 


Also, a message is sent to the target VM user when a file is spooled to the user’s 
reader. 


POWER 


SYSIN Jobs: When a job is first read in by POWER, the node and userid for 
notification are stored in the Job Header Record if ‘NTFY=’ was specified on the 
JOB card. This means that if a node, other than the originating node, is to be 
notified, then the onginating nodeid is destroyed by the notify node name. 


POWER notifies the “notify user” at the following times: 


e Job transmitted to another node (1RAOI) 
e Job completes execution or is abnormally terminated (1Q5DI) 


SYSOUT Jobs: POWER notifies the “notify user” at the following tumes: 


e Job’s output transmitted to another node (1RAOI) 
e Job’s output received at the destination node (1RBSJ) 


Any abnormal termination of a job’s output transmission is only recorded at the 
system console. 


Summary of Notification Messages 


Below is a table summarizing the various notification message-IDs sent by NJE 
systems to the submitting, or “Notify” user. See also Figure 3-1 on page 3-15 for 
a summary of operator messages issued for job transmissions. 


JES2 JES3 RSCS POWER 


$HASP526 | IAT9199 DMTxxx147 | 1RAOI 


- Received at Intermed. Node ae ae 
- Received at Execution Node $HASP122 | IAT9140 lee 
- Ended Execution SHASPI65 |- = {- ss 1 QDI 


Ee eee 
SysouT ibs SOSC~—SSSSCSC~‘idCSSC‘“‘;*~*” 
- Queued on Execution Node - 
ene [Semana ae 
- to Destination User (14) (15) (16) 


Figure 4-10. Notifications Sent by System 


13, See APAR OY04055. 
14 Requires that JES2 Exit 13 set RC=8. 
Is Requires JES3 Exit 42. 


16 POWER (ICCF) users may not receive NETDATA files. 
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For RSCS, note that there is no distinction between SYSIN and SYSOUT files. 
Here the term “Execution Node” for SYSOUT files implies the “Sending Node”. 
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File Transmission 


Although NJE was designed for transmitting spool files, many use it to transmit a 
variety of other data objects including bulk data. There are basically two dif- 
ferent ways to send bulk data: by using NJE, and by using a mechanism external 
to NJE. 


NJE Facilities The NJE.approach usually involves a utility or program at the 
sending and receiving end to transform the bulk data into, and out of, spool file 
format. 


Non-NJE Facilities The other mechanisms do not use the subsystems spooling 
system or NJE, but communicate directly with another copy of itself through a 
teleprocessing access method.: OS data sets or CMS files may be sent between 


nodes many different ways. The most appropriate method is dependent on the 
following factors: 


1. File organization, record format and length of the data sets, 

2. Size of the file, 

3. What SCP and program products are available at the sending nodes, 

4. Who 1s initiating the transfer (e.g., interactive user or batch job), 

5. What SCP and program products are available at the receiving nodes, and 

6. Who the recipient is. 

Physical Transportation Mechanisms: Won't forget the old-fashioned method of 
sending reels of tape through the mail. One liability of NJE 1s that 1t can be very 
easy to misuse by sending enormous amounts of data to another node’s location. 
It is very easy to use the NJE facilities, but the impact on intermediate nodes can 


be devastating if there are no mechanisms to limit the size of files being sent. 


The following discussion should help select the nght file transmission mechanism. 
Not all facilities may be available on your system. 


MVS File Transmission Facilities 


The following mechanisms use NJE for data interchange: 


1. TSO/E Interactive Data Transmission Facility Program Product (5665-285, 
5665-293) 


2. Bulk Data Transfer Program Offering (5796-PKK) 
3. File Transfer Program (FTP) Program Product Version 1 (5748-XE6) 


4. MVS Utilities JEHMOVE, etc.) 
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The following mechanisms do not use NJE, but have their own transmission 
facilities: 


1. MVS/Bulk Data Transfer (MVS/BDT) Program Product (5665-302) 
2. File Transfer Program (FTP) Program Product Version 2.2 (5668-932) 


In addition, many users have. written their own programs to transmit bulk data. 
The above facilities are discussed below in order. 


TSO/E Interactive Data Transmission Facility 
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The TSO/E Interactive Data Transmission Facility (IDTF) is a set of two com- 
mands for TSO/E users to transmit and receive messages, notes, sequential and 
partitioned data sets to other users on the same system, or another system in the 
NJE network. 


A file sent by the IDTF has an external writer name that is identical to the 
remote/userid field in the data set header. Each data set 1s preceded by an 
internal header. The onginal records may be any record length, but TSO/E passes 
the records to JES2 as fixed-length 80-byte records without carriage control. 


When this type of file is received at the destination node, JES2 can invoke a user 
exit (Exit 13) to allow the installation to retain or delete the incoming file. This 
exit may also change the target userid. Based on a return code from the exit, 
JES2 issues the S$HASP549 message to the TSO user. 


If the userid is not valid for this system, either because the userid could not be 
found or exit 13 deleted the file, the sender is notified with the $HASP548 
message. 


When the output is successfully received at the destination node the sender 1s 
notified with the $HASP546 message. This does not mean that the intended 
TSO user actually got the data, only that it arrived at the destination node and 
was successfully stored on the JES2 spool. The TSO/E facility on the receiving 
node can send an acknowledgement back to the sender when it is successfully 
received by the TSO user through the us~ of the RECEIVE command. 


For more information on TSO/E, see the following: 


e TSO/E: Command Language Reference, SC28-1307 
e TSO/E: User's Guide, SC28-1333 
© TSO/E: Reference Summary, SX23-0015 


There is an equivalent function for VM/CMS users, except that only sequential 
files may be sent. A single member of a PDS can be sent to a VM user, but 
“SEQ” must be specified on the TRANSMIT command to cause it to be sent as 
a sequential file. See “WM File Transmission Facilities” on page 4-42 for more 
information. 


BDT Program Offering 


Other Utilities 


The Bulk Data Transfer program offering runs on any MVS system and has a 
sending and receiving component. This is primarily for batch users and requires 
no user or operator interaction on the receiving end. 


At the sending end, the BDTXMIT program reads the user-supplied JCL to 
unload sequential data sets and writes them with JCL to the JES internal reader 
in 80-byte records. The job-stream has the appropriate “ROUTE XEQ statement 
for transmission to another node by NJE. 


At the receiving end, the BDTRECV program reads the unloaded data set as 
SYSIN data and rebuilds it on the target system as specified by the JCL sub- 
mitted with the job on the sending end. 


See BDT Program Description/Operation Manual, SH20-2088, for more informa- 
tion. 


(Some users have modified it to run under CMS on a VM system by changing 
the logic which scans the TIOT.) 


In addition to the BDT program offering, the following utilities also can unload 
OS data sets into 80-column (card images) that can be sent to another node as a 
job stream (SYSIN or SYSOUT) and then rebuilt into a file at the destination. 


FTP Version I: Version 1 of the File Transfer Program allows users to transfer 
sequential files (on tape or disk) from one installation to another. FIP programs 
support VSE and MVS operating system environments, so they may be used to 
transfer files between any NJE systems. See FTP Program Reference and Oper- 
ations Manual, SH12-5342 for details. 


MVS Utilities: Much like the BDT program offering mentioned above, utilities 
such as IEHMOVE may be used to unload MVS data sets, but are more cum- 
bersome than BDT. See “Using OS Utilities to Send Bulk Data” on page B-29 
for some examples. 


VSE Utilities: The VSE RJE Remote Workstation Program (5746-RC9), along 
with its predecessors, had a set of File Transfer Utilities which can be used to 
convert sequential data sets to job streams and back again. These utilities had 
programs that would run on MVS, VSE and VM systems. For more informa- 
tion, see Job Networking Facilities, GG22-9042. 


Other File Transfer Products 


The following programs do not use NJE to transfer the data, but provide their 
own transmission facilities: 
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MVS/[Bulk Data Transfer: The BDT/MVS Program Product (not to be con- 
fused with the Program Offering above) enables an installation to copy data sets 
to or from other systems within an SNA network. Data transfers may be initi- 
ated by TSO users, system operators and batch programs. This is the recom- 
mended way to transfer large amounts of bulk data between MVS systems, but is 
not supported on other systems. 


FTP Version 2: FIP Version 2.2 is a successor to FTP Version 1 and Cross 
Domain Network Data Transfer. It can be used by MVS, VM and VSE users to 
transfer sequential and VSAM files between MVS, VM and VSE systems on a 
SNA network. It does not use NJE facilities, but communicates with other 
copies of FTP V2.2 via ACF/VTAM sessions. 


File Transmission on Other Systems 


VM File Transmission Facilities 
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The following mechanisms are available to CMS users which use RSCS Net- 
working for the actual transmission. 


l. SENDFILE facility 

2. NOTE facility 

3. PRINT and PUNCH commands with Spooled Virtual Devices 

4. Bulk Data Transfer program offering (5796-PKK) with modifications 


5. Other CMS Utilities like DISK DUMP and VMSG have all been replaced 
by SENDFILE. 


In addition, several users have written their own programs to transmit bulk data. 
The above facilities are discussed below in order 


SENDFILE: ‘This may be used to transmit files to users on the same computer 
system, or another system connected via RSCS Networking. 


Note Facility: ‘This cannot be used to send an existing file, but may be used to 
create a SYSOUT file (electronic memo) and send it to one or more users. 


PRINT or PUNCH Commands with Spooled Virtual Devices: If the file to be 
sent is already in the format of a print or punch file, then the PRINT or 
PUNCH CMS command can be used to send it to another node. Spool the 
virtual printer or punch to the RSCS Networking virtual machine, TAG it with 
the appropriate destination and attributes, and PRINT or PUNCH the file. 


At the destination node, the file will be placed in the virtual reader defined for the 
target userid, where it can be received with the CMS READ command. 


Bulk Data Transfer Program Offering: Modifications are required to run the 
BDT program offering in a CMS environment. The simplest fix is to delete the 
instructions which reference the TIOT and handle multiple files. 


Receiving Files on VM 


The CMS user must be careful to use the appropriate “receive” command when 
reading files in his reader. The RDRLIST command can be used to “peek” at 
(view) the files in his reader. 


Sending Command Receiving Command 

CMS SENDFILE CMS RECEIVE 

TSO/E TRANSMIT 

CMS PUNCH or PRINT CMS READCARD 
or RECEIVE 

CMS DISK DUMP CMS DISK LOAD 
or RECEIVE 


BDTXMIT P O* BDTRECV PO * 


Figure 4-11. Format of “receiving” Command Based on Sending Mechanism 


* Requires a modification to run under CMS. 


File Transmission - POWER 


VSE[VSAM File Transfer: NVSE/SP provides dialogs to transfer VSE/VSAM or 
VSE/ICCF members to other systems. The program is part of VSE/SP, uses 
NJE as the transport vehicle and does not have any prerequisites. The program 
builds a job-stream which contains the VSAM file in 80-byte records and the 
program which reconstructs the file at the target node. 


The user interface is interactive; VSE/SP provides panels for the user to describe 
which file to send where. 


See VSE/SP Networking SC33-6180 for details. 


File Transfer Program (FTP) Version I (5748-XE6): This is supported on both 
VSE and MVS. FTP basically works by reading the file and breaking it up into a 
job and placing it on spool (VSE/POWER or JES2) and letting the NJE function 
transfer the job to the other end where the file will be put back together again. 


File Transfer Program Version 2 (5668-932): Version 2 of FTP runs in VSE, 
VM and MVS. It isa VTAM APPL-to-APPL transmission and does not use 
NJE at all. The file is read and sent directly through VTAM to FTP at the other 
end and the file 1s rebuilt there. 


Both versions of FTP should be considered for file transfer. Version 1 1s more 
appropniate for light use and small files, whereas Version 2 is more appropriate 
for heavy use or large files. See the following section for some comparison 
charts. 
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JES2 NJE 


For MVS to MVS transfers, there are three primary choices: 


e MVS/BDT is the most elegant, is available to operators, TSO users and 
batch jobs. Also, it does not use JES spool or transmission facilities. 


e TSQ/E Interactive Data Transmission Facility is good for TSO users inter- 
changing files and notes, and for communicating with VM/CMS users. 


e FTP Version 2 also does not use spool or NJE transmission. It 1s supported 
by MVS (JES2 and JES3), VM and POWER and provides transmission 
checkpoint/restart. 


e BDT program offering is adequate for simple transmissions that can be initi- 
ated by batch job submissions if the files are not too large. 


For transfers between MVS and VM, most of the files are spool (print or punch) 
files which can be sent directly with NJE. 


For interactive transfers between MVS and VM users, the combination of TSO/E 
Interactive Data Transmission Facility and VM SENDFILE is best. 


For transfers between MVS and VSE, use FTP (either Version | or 2). 


The following chart may be useful in understanding the above combinations. 


FROM These Systems 


i = | 
SENDFILE FTP 
FTP Ver.2 
TSO/E SENDFILE FTP Ver .2 
FTP Ver.2 


Figure 4-12. Summary of File Transfer Mechanisms 


Comparison Chart 
Program Number 
Operating Systems 
MVS 

VM 

VSE 

File Organizations 
Sequential 
Partitioned 

VSAM 


Transmission Vchicle 


NJE 
Private Session 


User Interface 
Batch 

Interactive 
System Operator 


leatures 


Checkpointing 
RACE Protection 


Compatibility 


MVS/BDT BDT FTP FTP 


PP 


PO Vi V2 


CMS TSO/E 
SENDFILE IDTF 


5662-302 5796-PKK 5748-XE6 5668-932 5665-167 5665-285 


Yes 
No 
No 


Yes 
Yes 


Yes Yes Yes 
No No Yes 
No Yes Yes 
Yes Yes Yes 
No No No 
No NO Yes 
Yes Yes No 
No No Yes 
Yes Yes Yes 
No No Yes 
No No No 
No No Yes 
No No No 


No Yes 
Yes No 
No No 
Yes Yes 
No Yes 
No Yes 
Yes Yes 
No No 
No No 
Yes Yes 
NO NO 
No No 
No No 


VSE/SP 
File Trans 
5666-301 


The only two products in the above list that are compatible with another are 
CMS SENDFILE and TSO/E Interactive Data Transmission Facility. 
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Appendixes 


JES2 NJE 


Appendix A. Sample Networks 


BSC Network 


This appendix contains two sample networks, each with a JES2, JES3, VM and a 
VSE node. The first network has all BSC connections and the second 1s all 
SNA. The third will be a session between two copies of JES2 in the same CPU. 
They do not show all the parameters that can be specified, such as passwords, 
but they show a basic set of parameters to help the reader understand the basic 
interrelations. 


Below is a sample NJE network with four nodes (VM, JES3, JES2 and VSE) 
connected via BSC lines. Note that there are only four lines in the network. The 
JES2 node is directly connected to every node, and the VM and JES3 nodes are 
interconnected. This is an arbitrary configuration to show that all nodes don’t 
have to be connected with every other node. 


Endicott Kings ton 


< — Node—name — >/ KGNJ3 


Dallas Poughkeepsie 
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JES2 Initialization 


The statements required to define the sample NJE network are listed below. 


NJEDEF OWNNODE=2, 7% this Node *X/ 
NODENUM=4, /% #% of Nodes X¥/ 
LINENUM=3 /% # NJE lines*/ 


TPDEF BUFSIZE=1152,... /% Max. NJE Buffer Size X*/ 


Nl NAME=ENDVM /*% NJE Nodes */ 
N2 NAME=POKJ2 

N3 NAME=KGNJ3 

N4 NAME=DALVSE 


LINE6 UNIT=cua,TRANSP, ... 7% NJE lines ¥/ 
LINE? UNIT=cua,TRANSP, ... 
LINE&8 UNIT=cua, TRANSP, 


7¥% Predefine non-JES2 connections 

CONNECT NODEA=2,NODEB=1,MEMBA=1,MEMBB=1 
CONNECT NODEA=2,NODEB=3,MEMBA=1,MEMBB=1 
CONNECT NODEA=2,NODEB=4,MEMBA=1,MEMBB=1 
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Sample JES3 Network Definition 


The same sample network shown above with the JES2 parameters would be 
defined from the JES3 node’s perspective as shown in the following section. 


JES3 Initialization Statements 


NJERMT ,NAME=KGNJ3, 
HOME=YES,... 
x 


NJERMT ,NAME=ENDVM, 
TYPE=BSC, 
LINE=LNOA3 
STREAM=2, 
BFSIZ=1024, 
MAXLINE=1 

x 


NJERMT ,NAME=POKJ2, 
TYPE=BSC, 
LINE=LNOAG 
STREAM=2, 
BFSIZ=1152, 
MAXLINE=1 


x 
NJERMT,NAME=DALVSE, 
PATH=POKJ2 


LINE TO ENDVM 


DTYPE=NJELINE, 
JNAME=LNEOA3, 
JUNIT=C0A3,SY1,TP,ON) 


% LINE TO POKJ2 
DEVICE, 
DIYPE=NJELINE, 
JNAME=LNEOAG, 
JUNIT=COAG,SY1,TP,ON) 


SIZE=100 
CONSOLE, 

JNAME=NJECONS, 

TYPE=NETWORK 
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Sample RSCS Network Definition 


The above network would be defined from the RSCS node’s perspective as 
shown below. 


RSCS Network Definition 


Configuration File Statements 


* LOCAL localid 
LOCAL ENDVM 
LINK linkid type cuu 


LINK KGNJ3 NJE OE3 
LINK POKJ2 NJE OE2 


PARM linkid parameters 


PARM KGNJ53 BUFF=1024 ST=1 TA=0 
PARM POKJ2 BUFF=1024 ST=2 TA=1 


ROUTE nodeid linkid 
ROUTE DALVSE POKJ2 


Operator Commands: As an alternative to the above configuration file state- 
ments for the other nodes, the following operator commands can be used. 


*% DEFINE linkid TYPE NJE LINE cua <Parm parameters> 
DEFINE KGNJ3 TYPE NJE LINE OE3 P BUFF=1024 
DEFINE POKJ2 TYPE NJE LINE OE2 P BUFF=1024 


* ROUTE nodeid TO linkid 
ROUTE DALVSE TO POKJ2 


Note: Prefix all RSCS commands witu ’RSCS’ when entered from the RSCS 
console 
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Sample POWER Network Definition 


The sample network would be defined from the POWER node’s perspective as 
shown below. 


POWER Assembly 


POWER 


PNET=NDT1 


PLINE ADDR=X'1A2',TRNSP=YES 


Network Definition Table (NDT) Assembly 


NDT1 PNODE NODE=DALVSE, 
LOCAL=YES 


PNODE NODE=POKJ2, 
AUTH=JOB, 
BUFSIZE=1152 


NODE=KGNJ3, 
AUTH=JOB, 
ROUTE1=POKJ2 


NODE=ENDVM, 
AUTH=JOB, 
ROUTE1=POKJ2 
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SNA Network 


Below is a sample NJE network with four nodes (VM, JES3, JES2 and VSE) 
connected via SNA sessions. 


Endicott Kingston 
< — Node-name — 
< - — APPLID — - 
< -— — CDRM — - - 
<-- sscp — -- 


[a0 |< ~ — ner sebaren — - >[ 30 


NCP Subarea - — ->| 20 | 


- sscp — - - 
- CDRM — - - 
— APPLID — - 

ne 


Dallas Poughkeepsie 


Note that all nodes have a session with all the other nodes except for the 
VM-to-VSE and JES3-to-VSE combinations. This is arbitrary just to show that 
all nodes need not have a session with all other nodes in a SNA environment. 
NJE store-and-forward facilities may still be used with SNA connections. 
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JES2 Initialization 


The statements required to define the sample NJE network are listed below. 


NJEDEF OWNNODE=2, 
NODENUM=4, 
LINENUM=3 


TPDEF BUFSIZE=1152,... 


Nl NAME=ENDVM,SNA 
N2 NAME=POKJ2,SNA 
N3 NAME=KGNJ3,SNA 
N4 NAME=DALVSE,SNA 


APPL NODE=1,APPLID=ENDVMA 
APPL NODE=2,APPLID=POKJ2A 


APPL NODE=3,APPLID=KGNJ3A 
APPL NODE=4,APPLID=DALVSEA 


LOGON1 APPLID=POKJ2A 


LINE6 UNIT=SNA 
LINE? UNIT=SNA 
LINES UNIT=SNA 


this Node ¥X*¥/ 
# of Nodes X¥/ 
# NJE lines*¥/ 
Max. NJE Buffer Size X¥/ 


NJE Nodes X/ 


APPL-IDs 


VTAM API 
NJE lines 


7% Predefine non-JES2 connections 

CONNECT NODEA=2,NODEB=1,MEMBA=1,MEMBB=1 
CONNECT NODEA=2,NODEB=3,MEMBA=1,MEMBB=1 
CONNECT NODEA=2, NODEB=4, MEMBA=1,MEMBB=1 


VTAM Network Definition (for JES2) 


Without showing all the parameters, the vanous VTAM parameters and lists used 
to define the topology of the network and BIND parameters are diagramed 


below. 
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JES2 NJE 


VTAM Start Options 
ATCSTRJ2 


CONF IG=J2 ——] Configuration 
HOSTSA=2 > ATCCONJ2 


X-Domain Resources Vv X—Domain 
J2CDRSC < JZ2CDRM Resource Mgr. 


VBUILD TYPE=CDRSC VBUILD TYPE=CDRM 
ENDVMA CDRSC CDRM=ENDXDOR>I>|ENDXDR CDRM SUBAREA=1 
POKXDR CDRM SUBAREA=2 
KGNJ3ZA CDRSC CDRM=KGNXDR>I>|KGNXDR CDRM SUBAREA=3 
DALVSEA CDRSC CDRM=DALXDR>;>|DALXDR CDRM SUBAREA=4 


Paths to Other Subareas 
PATHJ2 < 


VBUILD TYPE=PATH 
PATH DESTSA=(1,10),ERO=( 20,1) 
PATH DESTSA=( 20 ),ERO=( 20,1) 


PATH DESTSA=(3,30),ERO=( 20,1) 
PATH DESTSA=(4,40 ) ,ERO=(20,1) 


Local VTAM Applications 
APPLJ2 < 


VBUILD TYPE=APPL 
POKJZA APPL 
AUTH=(ACQ,...)> 
VPACING=4, 
DETAB=NJETAB, 


| DLOGMOD=LMDNJE 


Logmode Table 
> NJETAB 


Vv: 


NJETAB MODETAB 
MODEENT LOGMODE=LMDNJE » 


SSNDPAC=4, eee 


Sample JES3 Network Definition 


The same sample network shown above with the JES2 parameters would be 
defined from the JES3 node’s perspective as shown in the following section. 


JES3 - MVS/BDT Relationship: The figure below show how JES3 and BDT 
interact. SSI 1s used for communication between JES3 and MVS/BDT. Jobs 
and SYSOUT reside on JES3 spool. 


MVS|BDT View of the NJE Network 


KGNJ3/KGNJ3A ENDVM/ENDVMA 


POKJ2/POKJ2ZA 


JES3 knows the names of all NJE nodes and the first NJE node in path to the 
node. BDT knows the node names and application names for all adjacent SNA 
NJE nodes. VITAM knows about all the network resources, routes, etc. 
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JES3 Initialization Statements 


NJERMT, NAME=KGNJ3,HOME=YES, BDTID=KGNJ3 


x 
NJERMT,NAME=ENDVM, TYPE=SNA,... 
x% 


NJERMT,NAME=POKJ2,TYPE=SNA,... 
x 


NJERMT ,NAME=DALVSE, PATH=POKJ2 
x 


NJECONS, SIZE=100 
CONSOLE, JNAME=NJECONS, TYPE=NETWORK 
CONSOLE, JNAME=BDT DUMMY, TYPE=RJP 


Ha we a a a — ea = ee = ee ee SS 
* DEFAULT BDT DEFINITION 


SYSID,NAME=KGNJ3 


MVS/BDT Initialization Statements 


x 

% VM NODE AT ENDICOTT 
xX 

BDTNODE,N=ENDVM, 
APPL=ENDVMA, 
BUFS2Z=4096, 

LU=05, 

TYPE=NJE 

x 


* JES2 NODE AT POUGHKEEPSIE 
xX 

BDTNODE, N=POKJ2, 
APPL=POKJ2A, 

BUFSZ=4096, 

LU=05, 

TYPE=NJE 

x 


MVS/BDT SYSTEM ID 


SNABUF, SIZE=4096, 
PRI=015,SEC=(€015,05), 
AUTODEL=YES 
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ACF/VTAM Initialization Statements (for JES3) 


ATCSTRJ3 
>| ATCCONJ3 


>|PATHJ3 


>| APPLJ3 
> |NJETAB 


ATCSTRJ3 - VTAM Start Options 


HOSTSA=3, 
MAXSUBA=63, 
CONFIG=J3, 
CSALIMIT=0, 
ITLIM=0, 
SSCPID=3, 
MAXAPPL=150, 
VTAMEAS=150, 
IOBUF=(€350,255,19,,50,50), 
CRPLBUF=(€350,,15,,20,58), 
UECBUF=(246,,25,,30,30), 
LFBUF=(€150,,0,,10,1), 
LPBUF=(€280,,15,,50,50), 
SPBUF=(€600,,0,,50,1), 
WPBUF=(246,,0,,10,1) 


ATCCONJ3 - Network Configuration 


KGNCDRSC, 
KGNCDRM, 
PATHJ3, 
APPLJ3 


KGNCDRSC - X-Domain Resources 


VBUILD TYPE=CDRSC 
ENDVMA CDRSC CDRM=ENDXDR 


POKJ2A CDRSC CDRM=POKXDR 


KGNCDRM - X-Domain Res Mgrs 
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VBUILD TYPE=CDRM 
ENDXDR CDRM SUBAREA=1,ISTATUS=INACTIVE 


POKXDR CDRM SUBAREA=2, ISTATUS=INACTIVE 
KGNXDR CDRM SUBAREA=3 


PATHJ3 - Path Definitions: Note that there is not a SNA path to Dallas (SA 4) 
because we arbitrarily decided to use NJE store and forwarding to reach that 
node. 


VBUILD TYPE=PATH 
KGNJ3 PATH DESTSA=(1,2,10,20,30), 
ERO=(€30,1), 
VRO=0 


APPLJ3 - Local Applications 


VBUILD TYPE=APPL 
KGNJ3A APPL AUTH=ACQ, 
VPACING=2, 
MODETAB=NJETAB, 
DLOGMOD=LMODNJE 


NJETAB - Logmode Table 


NJETAB MODETAB 

LMODNJE MODEENT LOGMODE=LMODNJE, 
COMPROT=X'4020', 
FMPROF=X'03', 
PRIPROT=X'72', 
PSERVIC=X*000000000000000000000000', 
SECPROT=X'72', 
PSNDPAC=X'02', 
PRCVPAC=X'02', 
SSNDPAC=X'02', 


RUSIZES=X*'0000', 
TSPROF=X'03', 
TYPE=X'O1', 
COS=X*'00', 
ENCR=X‘'00' 


om FR FF FR FR FR FR FR FR FFA 
W EHKERE ANNE He ee 
ww Ned Nd Nd Nd Ce Ce ed ee ee ee 


€1) MVS/BDT forces the values as shown. 
€2) MVS/BDT does not check these values. 
C3) MVS/BDT forces bits 0 and 1 to zero. 
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Sample RSCS Network Definition 


The above network would be defined from the RSCS node’s perspective as 
shown below. 


RSCS Network Definition 


Configuration File Statements 


¥ LOCAL localid 
LOCAL ENDVM 
LINK linkid type cu z dp luname’'  logmode 


LINK KGNJ3 SNANJE ® X KGNJ3SA xX 
LINK POKJ2 SNANJE ® X POKJ2ZA X 


PARM linkid parameters 


PARM KGNJ3 BUFF=1024 ST=1 TA=0 
PARM POKJ2 BUFF=1024 ST=2 TA=1 


ROUTE nodeid linkid 
ROUTE DALVSE POKJ2 


Operator Commands (an alternative) 


* DEFINE linkid TYPE SNANJE <LUName name> 
¥ <LOGMode name> 
¥ <Parm parameters> 


DEFINE KGNJ3 TYPE SNANJE LUN KGNJ3A 
P BUFF=1024 ST=1 TA=0 


DEFINE POKJ2 TYPE SNANJE LUN POKJ2A 
P BUFF=1024 ST=2 TA=1 


*% ROUTE nodeid TO linkid 
ROUTE DALVSE TO POKJ2 


Note: Prefix all RSCS commands with ’RSCS’ when entered from the RSCS 
console 
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VTAM Network Definition (for RSCS) 


A-14 


JES2 NJE 


ATCSTRVM 
> | ATCCONVM 


>|RSCSTAB 


Each list except RSCSTAB resides in ‘listhame VTAMLST’ 


ATCSTRVM - VTAM Start Options 


HOSTSA=1, 


CONFIG=VM, 
SSCPID=1 


ATCCONVM - Network Configuration 


VMCDRSC, 
VMCDRM, 
PATHVM, 
APPLVM 


VMCDRSC - X-Domain Resources 


VBUILD TYPE=CDRSC 
KGNJ3A CDRSC CDRM=KGNXDR 
POKJ2A CDRSC CDRM=POKXDR 


VMCDRM - X-Domain Resource Managers 


VBUILD TYPE=CDRM 
ENDXDR CDRM SUBAREA=1 


POKXDR CDRM SUBAREA=2 
KGNXDR CDRM SUBAREA=3 


PATHVM - Path Definitions: Note that there is not a SNA path to Dallas (SA 
4) because we arbitrarily decided to use NJE store and forwarding through 
Pokipsy (POKJ2) to reach that node. 


VBUILD TYPE=PATH | 
ENDVM PATH DESTSA=(2,3,10,20,30), 


ERO=(€10,1), 
VRO=0 


APPLYM - Local Applications 


VBUILD TYPE=APPL 
ENDVMA APPL AUTH=CACQ), 
AUTHEXIT=YES, 
VPACING=n, 
MODETAB=RSCSTAB, 
DLOGMOD=RSCSNJEO 


(1) This keyword value must be specified 


RSCSTAB - Logon Mode Table: RSCSTAB resides in ‘RSCSTAB LOADLIB’ 


RSCSTAB MODETAB 

RSCSNJEO MODEENT LOGMODE=RSCSNJEO, 
TYPE=X'0l1', 
FMPROF=X'03', 
TSPROF=X'03', 
PRIPROT=X'72', 
SECPROT=X'72', 
COMPROT=X'4020', 
SSNDPAC=X'nn', 
SRCVPAC=X'nn', 
RUSIZES=X'0000', 
PSNDPAC=X'nn', 
PSERVIC=X'000000000000000000000000', 
ENCR=B'0000' 


uF FR FR FR FR FR FR FR FR FR FR FA 
fmt met PA) bt PAD PA) et et at at bt Bt 
Need Ned Ned Wd Nw fw Od fed ed we we 


€1) RSCS forces the values as shown 
€2) RSCS does not check these values 
€3) This is a suggested table entry name 
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Sample POWER Network Definition 


The sample network would be defined from the POWER node’s perspective as 
shown below. See VSE/POWER Version II Networking Design Guide 
GG24-1570 for some more complete examples. 


POWER Assembly 


POWER 


Nodal Definition Table (NDT) 


NDTSNA PNODE 


VTAM Network Definition (for POWER) 


ATCSTRVS 
>| ATCCONVS 
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PNET=NDTSNA 


NODE=DALVSE, 
APPLID=DALVSEA, 
LOCAL=YES 


NODE=POKJ2, 
APPLID=POKJ2A, 
AUTH=JOB, 
BUFSIZE=1152 


NODE=KGNJ3, 
AUTH=JOB, 
ROUTE1=POKJ2 


NODE=ENDVM, 
AUTH=JOB, 
ROUTE1=POKJ2 


ATCSTRVS - VTAM Start Options 


HOSTSA=4, 


CONFIG=VS, 
SSCP ID=4 


ATCCONVS - Network Configuration 


VSECDRSC, VSECDRM, PATHVSE,APPLVSE 


VSECDRSC - X-Domain Resources 


VBUILD TYPE=CDRSC 


POKJ2A CDRSC CDRM=POKXDR 


VSECDRM - X-Domain Resource Managers 


VBUILD TYPE=CDRM 
POKXDR CDRM SUBAREA=2 
DALXDR CDRM SUBAREA=4 


PATHVSE - Path Definitions: Note that there is not a SNA path to Endicott 
(SA 1) or Kingston (SA 3) because we arbitranly decided to use NJE store and 
forwarding through Pokipsy (POKJ2) to reach those nodes. 


VBUILD TYPE=PATH 

PATH DESTSA=(€2,20,40), 
ERO=(40,1), 
VRO=0 


APPLVSE - Local Applications 


VBUILD TYPE=APPL 
DALVSEA APPL AUTH=CACQ), 
AUTHEXIT=YES, 
VPACING=n, 
MODETAB=PNETTAB, 
DLOGMOD=PNETNJEO 


PNETTAB - Logon Mode Table 


PNETTAB MODETAB 
PNETNJEO MODEENT LOGMODE=PNETNJEO, 
SRCVPAC=3, 


PSNDPAC=3, 
SSNDPAC=3 
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Connection in the Same MVS System 


JES2 Initialization 


A-18 JES2NJE 


Below is a sample NJE network between the pnmary and secondary copies of 
JES2. They may be the same level of JES2 (and same load modules), or different 
versions. This connection requires no hardware links or communication con- 
troller. It is done wholly through an application-to-application (intra-domain) 
SNA session through VTAM. 


This is a very useful connection when testing out a new version of JES2, or when 
testing out an NJE network before the hardware or other system(s) are available. 


Pokipsy MVS System 


The statements required to define the sample NJE network are listed below. 


Different 
| JESA (Secondary } 


% INJEDEF OWNNODE=2, 
NODENUM=2 ;» 
LINENUM=1 


JES2 (Primary ) 


NJEDEF OWNNODE=1, 
NODENUM=2 » 
LINENUM=1 


N1 NAME =POKJ2 »SNA N1 NAME =POKJ2 »SNA 


N2 NAME =POKJX ,SNA 
LINE6 UNIT=SNA 


APPL NODE=1, 
APPLID=POKJ2A 


APPL NODE=2, 
APPLID=POKJXA 


LOGON1 APPLID=POKJ2A 
CONDEF CONCHAR=$ 

SPOOLDEF DSNAME=aaaa 
CKPTDEF DSNAME=cccc 


N2 NAME =POKJX SNA 
LINE7 UNIT=SNA 


APPL NODE=1, 
APPL~~ =POKJ2A 
APPL NODE=:., 
APPLID=POKJXA 
LOGON1 APPLID=POKJXA 


CONDEF CONCHAR=. 


SPOOLDEF DSNAME=bbbb 


CKPTDEF DSNAME=dddd 


VTAM Network Definition (for JES2) 


Assuming VTAM is already installed and operational, the only VITAM list 
required is for the definition of the two copies of JES2, which is pointed to from 
the VTAM Configuration member. 

APPLJ2 


VBUILD TYPE=APPL 
POKJZA APPL AUTH=ACQ <— Primary 


x 
POKJXA APPL AUTH=ACQ <— Secondary 


Other parameters may be specified such as VPACING or MODETAB, but are 
not necessary at the beginning. Note that the CDRM, CDRSC and PATH 
members are not required, because there are no other sub-areas involved in this 
network. (Single-domain) 
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Increasing Throughput between SNA JES2 NJE Nodes 


This was published in WSC Flash 8703 in 1/87 by Scott Wood (INFO item 
G21494). 


Installations needing increased data traffic between SNA NJE nodes may wish to 
consider: 


1. asecond session between single nodes, 


2. additional sessions between JES2 sites by using JES2 secondary subsystems. 
The secondaries may or may not be sharing spool with their primanies. 


3. combinations of the above. 

These techniques can increase overall throughput by providing access to under- 

used or additional link capacity. This document discusses the first two tech- 

niques. The last is left as an exercise for the reader. 

Of course, standard JES2 NJE tuning should precede these steps, including: 

e using the largest possible teleprocessing buffer size (3840, or at least 1792) 
between nodes. See “JES2 TP Buffer Size and Virtual Storage Optimization” 
on page B-12 for recommendations. 


e providing an adequate number of JES2 teleprocessing buffers, 


e for SNA lines, using reasonably large, non-zero, pacing and/or VR pacing 
values, 


e providing adequate virtual and real storage for JES2 and VTAM, 
e = =giving JES2 and VTAM high MVS dispatching pnority, 
e providing consistent tuning parameters at each level of tuning in the SNA 


hierarchy. (Don’t undo the benefits of large JES2 buffers by using small 
SDLC PIUs, for example.) 


Second Session Between Two JES2 Systems 


B-2 


JES2 NJE 


In this method, installations needing increased data traffic between SNA NJE 
nodes may exploit a subtlety in standard JES2 SNA NJE operation. 


In JES2 SNA NJE, the application issuing the $SN,A= to start networking 
between its node and another SNA node becomes the pnmary SNA LU. The 
VTAM ACB JES2 uses for this session is the one identified in the JES2 
LOGON | initialization statement. However, there is nothing to prevent the 
other JES2 node from initiating a session with a VTAM ACB other than that 
created by LOGON1. You do this by having the remote SNA NJE JES2 node 
issue a $SN,A= command, this time naming the JES2 application as the one 
identified by the LOGON 2 statement of the target JES2 node. 


An example should help clanfy things. Consider Figure B-1 on page B-3. 


LINE10 
——_—_—_—_——_/ /—————>_ Seattle 
SLU:NYJESA PLU: SEJES2 JES2 


LINE 22 
> 


a oy 
PLU:NYJES2 SLU:SEJESA 


JES2 definitions 


LOGON] APPLID=NYJES2 LOGON] APPLID=SEJES2 
LOGON2 APPLID=NYJESA LOGON2 APPLID=SEJESA 
LINE1O UNIT=SNA LINE1O UNIT=SNA 
LINE22 UNIT=SNA LINE22 UNIT=SNA 
NJEDEF OWNNODE=2, NJEDEF OWNNODE=3, 

PATH=2> PATH=2, 

JRNUM=2, ... JRNUM=2 » : 
TPDEF BUFSIZE=3840, TPDEF BUFSIZE=3860, 

BUFNUM=200 BUFNUM=200 

APPL APPLID=NYJES2 ,NODE=2 APPL APPLID=NYJES2 ,NODE=2 
APPL APPLID=NYJESA,NODE=2 APPL APPLID=NYJESA,NODE=2 
APPL APPLID=SEJES2 ,NODE=3 APPL APPLID=SEJES2 ,NODE=3 
APPL APPLID=SEJESA,NODE=3 APPL APPLID=SEJESA,NODE=3 
N2 NAME=NY,SNA, ... N2 NAME=NY,SNA, 
N3 NAME=SE,SNA, ... N3 NAME=SE ,SNA, 


Operator commands 


$S LGN1 $S_ LGN1 
$S LGN2 $S LGN2 
$S LNE10 $S LNE10 
$S LNE22 $S_ LNE22 
$SN LNE22,A=SEJESA ee 
ae $SN LNE10,A=NYJESA 
$P L10.JT1 $P L10.JT1 

$P L10.JT2 $P L10.JT2 

$P L22.ST1 $P L22.ST1 

$P L22.ST2 $P L22.ST2 


Figure B-1. Two sessions between adjacent JES2 SNA NJE nodes. Some initializa- 
tion statements are abbre ‘ited for clarity. See SC23-0065-3 or equivalent 
for coding details. See text for comments on the procedure. 


Once each node starts its session with the remote’s LOGON2 application, there 
are two sessions between the SNA nodes. Data is sent on a session basis from 
each node and received on an ACB basis at each node. For NJE JES2 uses the 
ACB identified by the LOGON] initialization statement for sends but accepts 
data from sessions identified by either of the ACBs named by the LOGON 1 or 
LOGON 2 initialization statements. 


Since both JES2 nodes still have the same JES2 NJE nodenames, routing tech- 
niques are the same as with a single session. In fact, there is no way to cause 
jobs or output to travel on one versus another of the two sessions unless specific 
job or output transmitters or receivers are drained. So, in Figure B-1, LINE22 1s 
devoted to job sending and receiving and LINE10 is devoted to output sending 
and receiving; LINE22 will never get SYSOUT and LINE10 will never get jobs. 
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Since JES2 work selection facilities do not apply to NJE, further selectivity is not 
possible without modifying JES2 code. 


The transmission media can differ unbeknownst to the JES2 applications 
involved. VWITAM CTC, single SDLC lines, or multiple SDLC lines can be used 
and their related classes of service and pacing values can vary. If the second 
session used a very high-speed link, for example, you could activate that during 
periods when line costs were low or when traffic volume required additional 
capacity. 


Some additional comments about the procedure in Figure B-1 on page B-3: 


e The ‘APPL APPLID= ...’ statements are required even though these state- 
ments may not be defining multi-access spool nodes. The statements are 
required in order to cause JES2 not to generate VTAM application names 
using parameters from Nnnnn initialization statements. 


e As always, class of service and pacing valucs will be derived from the 
logmode table of the secondary LU, 1.e., the APPL specified by the 
LOGON2 statement. 


e After session establishment, all NJE transmitters and receivers (ST, SR, JT, 
JR) are initially in ‘started’ and ‘inactive’ status, so the operator only needs 
to drain what he doesn’t want. In our example, if LINE22 at both sides 
cannot send SYSOUT, then the other side cannot receive SYSOUT on 
LINE22. The same goes for jobs on LINE10. 


e Our example will only work as long as both sides always start LINE10 before 
starting LINE22. The LINEnnnn with UNIT=SNA started last will be the 
first LINEnnnn JES2 ‘randomly’ selects for a session request from another 
node. As long as no other JES2 SNA device (such as an RJE station or 
another NJE node) grabs either one of these lines, the procedure will work. 


e We also must assume that N2 (NY) _ issues’ his _ start-up 
‘$SN,LNE22,A = SEJESA’ before N3 (SE) enters his 
‘'SSN,LNEIO,A= NYJESA’. If N3 issued first, we would have N3/LINEIO 
connected to N2/LINE22. Then when N2 issued its command, we would 
get a SHASP679 resource shortage because N2/LINE22 is already being used. 


e In view of the order dependencies in starting lines and sessions mentioned in 
the last three points, if there 1s no particular need to force jobs onto one 
LINEnnnn and SYSOUT onto another, consider avoiding the complications 
by not draining any transmitters and by not coding “LNEnnnn’ in the $SN 
commands. Performance benefits, if any, will occur without this kind of 
work selection and operation will be much simpler. 


e Don't use the PASSWORD= parameter on the LINEnnnn statement since 
it is difficult to control which LINEnnnn JES2 will select for an SNA session 
(see above). If you must use passwords, consider using nodal passwords, 1.e., 
PASSWORD= on the Nnnnn statement. 


Performance benefits, if any are obtained at all, are likely to be due to decreased 
queueing into VITAM from JES2 and the additional capacity from the links 


assigned to the second session. We must emphasize that this environment has not 
been measured as to virtual or real storage costs or performance benefits. Results 
which may be obtained in specific environments may vary significantly. Users of 
this information should verify the applicable data for the specific environment 
intended. 


Additional Sessions via Secondary Subsystems 


In this method, installations needing increased data traffic between SNA NJE 
nodes use standard JES2 secondary subsystem functions to obtain additional ses- 
sions between different JES2 sites. 


A secondary JES2 at each of two nodes can be used to increase line utilization 
and improve node-to-node throughput, assuming link capacity is available and 
enough CPU cycles and storage is available at each node. 


Again, the transmission media can differ unbeknownst to the JES2 applications 
involved. VTAM CTC, single SDLC lines, or multiple SDLC lines can be used 
and their related classes of service and pacing values can vary. If the secondary 
JES2 used a very high-speed link, for example, you could activate the secondary 
during periods when line costs were low or when traffic volume required addi- 
tional capacity. 


The procedure: 


e Define a secondary at each node using the directions and cautions found in 
SC23-0065-3 under the caption ‘Secondary Subsystem Options.’ 


e Give the secondary a MASDEF OWNSID= value different than the 
primary, just like a member of a multi-access spool node. 


e Give each JES2 at a node a unique VITAM applid. Applids are provided to 
VTAM based on the LOGONn JES2 initialization parameter. Naturally, 
provide additional VTAM APPL and CDRM statements at each node. 


e Consider routing techniques. The secondary could share spool with the 
primary and thus select NJE won: for transmission and be a target node for 
remote sites jointly with the primary. Alternatively, the secondary could have 
its own spool and become the target node for both local (primary) JES2 as 
well as remote nodes. 


Some possible advantages of the secondary sharing spool with the pnmary 
include: 


— simplified routing for users and JES2 systems programmers than would 
be the case using separate spool 


— no additional nodal definitions needed in the network 


— cleaner management of the additional capacity than might be obtained 
without using a secondary 


Some possible advantages of having a separate spool for the secondary: 
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— eliminate checkpoint contention 
— even more control of access to this node 


All secondaries require virtual and real storage of their own and require oper- 
ator training if used in daily operations. However, using a secondary offers 
the possibility of removing from the primary the sometimes high virtual 
storage requirements for teleprocessing buffers. 


« If the pnmary and secondary JES2 share a common spool, give each JES2 


primary and secondary at a given node identical NJIEDEF OWNNODE= , 
N1, N2....Nnnnn statements. If the primary and secondary JES2 don’t share 
spool, provide unique NJEDEF OWNNODE= values but identical N1, N2 
... Nnnnn statements. 


Refer to SC23-0065-3, MVS/XA SPL: JES2 Initialization and Tuning, or equiv- 
alent for JES2 NJE initialization parameter coding details. 


Refer to GG22-9378, How JES2 Uses SNA for RJE and NJE, for a general 
understanding of JES2’s use of SNA. 


Networking Advanced Function Printing Data 


This was published in WSF Flash 8711 in 3/87 by Jill Shindelman. 


With the general availability of PSF/VM in December 1986, all three System/370 
operating systems now have the ability to use page mode pnnters. The 3800-3 
running in page mode and the 3820 can be attached to MVS, VM, or VSE, and 
Advanced Function Printing software can run in all three environments. 


This wide choice of attachments gives multi-CPU users a great deal of flexibility 
to create output on any system and send it to a PSF system for printing on a 
page mode printer. When planning an NJE network where page mode pninters 
arc involved, it 1s necessary to understand the software required to send the data 
successfully through the NJE network. 


Factors associated with networking output data 


To determine the levels of networking software required in a particular configura- 
tion, three questions must be answered: 


e Is line mode or page mode data to be sent? 


Iixamples of line mode data are traditional computer listings, consisting of 
fixed-length records not to excced 255 bytes in length. Common examples of 
page mode data are GDDM graphic output in page segment or document 
format, and DCF Release 3 output formatted for a 3820 or 38PP device. 
These data sets consist of vanable-length records that can be up to 32K 
bytes. 


e Are PAGEDEF and FORMDEF names to be associated with the data? 


Line mode data can have a one- to six-byte PAGEDEF or FORMDEF 
name associated with it. Information in the PAGEDEF 1s used to format 
the data itself, while information in the FORMDEF 1s used to specify form 
characteristics, such as data ongin on the page, or simplex/duplex or bin 
selection on the 3820. Page mode data 1s already fully formatted, so a 
PAGEDEF 1s not used. However, a FORMDEF can be used with a page 
mode data set. 


e What operating systems are running on the sending, receiving, and interme- 
diate nodes? 


The levels of MVS/JES, VM/RSCS, and VSE/POWER required when net- 
working page printer data may be different depending on where the system 
falls in the network path taken by the data to be printed. See the following 
paragraphs for details. 


Operating system levels 
A detailed description of networking data formats can be found in WSC Tech- 
nical Bulletin GG22-9373-2, “Network Job Entry Formats and Protocols.” The 


formats illustrated in the -2 version of this manual are fully supported by the 
operating system releases shown in Figure B-2. 
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# MVS/SP - JES2 Version 1.3.4 or Version 2.1.2 (these two 
are ee are identical, and have the same FMID of 
J 0 


=» MVS/SP - JES3 Version 1.3.4 or Version 2.1.2 (these two 
aTese say are identical, and have the same FMID of 
J 29 


#® RSCS Networking Version 2.2 (to use this version of RSCS 
with networking of page mode data, you must also have 
VM/SP Release 5 or VM/SP HPO Release 5, which support 
Page mode data records on the VM spool) 


# VSE/POWER Version 2.3 


Figure B-2. Operating system levels that support networking of output data. Later 
levels will also work unless the announcement specifically states otherwise. 


The NJE support provided by the operating systems listed in Figure B-2 contains 
three key elements for users of page mode printers: 


1. The data streams sent across the network can consist of variable length 
records up to 32K in length. 


2. The value X’5A’ is valid in the carriage control byte position. 


3. The networking data set header contains a new “output processing section” 
that includes a great deal of information about data sets which are intended 
for printing on page printers under control of PSF. The fields in this section 
which are of greatest interest to users are those that specify the name of a 
PAGEDEF and the name of a FORMDEF. 


From this it can be seen that if all the systems in the network are at the levels 
shown in Figure B-2, the user will have no problem sending any type of data 
from any system to a PSF-controlled page printer on any other system in the 
network. Certain restrictions apply when earlier levels are used. 


Networking line mode data 


If traditional line mode data is to be sem. to a remote system for printing on a 
PSF-controlled printer, no special considerations are needed. Since the receiving 
node will be running PSF, its operating system must be at a level that supports 
PSF, but the data going across the network looks no different from the tradi- 
tional 1403 data stream. Sending and intermediate nodes can be at any level that 
supports NJE. 


Networking page mode data 


Page mode data, also known as AFPDS format data,' contains vanable length 
records up to 32K bytes in length, and each logical record begins with a X’5A’ 
character. This type of data is not supported in early releases of the networking 


I AFPDS stands for “Advanced Function Printing Data Stream.” The AFPDS 
records are documented in Print Services Facility Data Stream Reference, 
SH35-0073. 


products, which could only handle fixed-length records of up to 255 bytes each. 
Many users wrote special “bridge” programs that de-blocked the page mode data 
into 80-byte records, and then sent the data across the network along with a job 
that would re-block the records back to their original format and write them to 
the spool for printing. 


This bridge code is no longer needed once the user is running one of the oper- 
ating systems listed in Figure B-2. 


Associating PAGEDEF and FORMDEF names with line data 


It was not possible to associate specific PAGEDEF and FORMDEF names with 
line data records prior to the releases of software listed in Figure B-2. A partial 
circumvention that was occasionally used consisted of giving a one-to-four- 
character alias name to a PAGEDEF, and then specifying the alias name in the 
FCB parameter associated with the data set. Because of the hierarchy of JCL 
parameters used by PSF when choosing a PAGEDEF to format a data set, the 
FCB approach would work. This is true in all three operating systems, at the 
levels shown in Figure B-4. 


FORMDEFs, on the other hand, have no equivalent in JCL used with line mode 
printing. There is no way prior to the systems listed in Figure B-2 to associate a 
FORMDEF name with a data set sent across a network for printing. 


Associating a FORMDEF name with page mode data 


Page mode data sets contain complete formatting information interspersed with 
the data, so there is no need to refer to PAGEDEF names when printing them. 
But if a FORMDEF is needed in conjunction with a networked page mode data 
set, the operating system levels in Figure B-2 must be used on the originating 
and receiving systems. 


VM special case 1: Using PAGEDEF and FORMDEF names with data to be 
sent across a network 


PSF/VM, which supports the page mode 3800-3 and the 3820 in a VM environ- 
ment, provides the “PSF” commar™“ for use in sending data to one of these 
printers. Among the parameters on tne PSF command are those that allow the 
specification of PAGEDEFs and FORMDEFs to be used when the data is 
printed. 


So long as a user has a single VM system where the PSF/VM software 1s installed 
and to which the pninters are physically attached, there is nothing unusual about 
this. But if a VM user wants to send line data across a network and associate a 
PAGEDEF and FORMDEF name with tt, or if the user wants to send page data 
with a FORMDEF name, there must be some way available to him to provide 
those names to the network. 


In VM, this is done in a new Release 5 control block. Furthermore, it is 
PSF/VM that stores the PAGEDEF and FORMDEF names into the control 
block pnor to sending them along with the data across a network. As a result, 
VM/SP Release 5 1s the minimum level of this operating system required if the 
goal is to send the PAGEDEF and FORMDEF names along with the data. And 
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if this function is to be provided without user additions to VM, the PSF/VM 
program product must be installed on the sending VM node to provide the user 
with the “PSF” command where the PAGEDEF and FORMDEF can be named. 


If the user does not want to install PSF/VM just to get this function on a system 
where no page mode printers are attached, he has the option of writing a REXX 
EXEC to accomplish the control-block-store function instead. 


VM special case 2: Sending FORMDEFs or PAGEDEFs along with data in a 
VM-to-VM network 


A unique feature of the PAGEDEF and FORMDEF parameters on the PSF 
command in VM is that the user can include the PAGEDEF or FORMDEF itself 
along with the data, as an alternative to providing a name which will then be 
used to retrieve a PAGEDEF or FORMDEF from the appropriate library on the 
receiving system. 


This “inline resource object” function is available only in PSF/VM, so a data 
stream containing such objects could not be sent to a VSE or MVS system for 
page mode printing. Such a data stream can, however, be sent to another system 
running PSF/VM, but only if the sending and receiving systems are at VM/SP 
Release 5 or VM/SP HPO Release 5 with RSCS Version 2.2. 


Summary of data networking considerations in an AFP environment 


If only line mode data is being sent across a network, there are no special consid- 
erations regarding operating system levels at the sending, receiving, or interme- 
diate nodes. If page mode data is being sent, it is possible to choose any 
combination of MVS, VM, and VSE operating systems at any node so long as 
they are at the levels shown in Figure B-3 and Figure B-4. 


MVS/7SP JES2 
A eee ee ae dame ee re 
CFMID HJE2330) 


MVS/SP JES3 
1.3.4 7 2.1.2 
CFMID HJS2329) 


VM/SP or VM/HPO 
Release 5 with 


RSCS 2.2 
(see note 2) 


oe oe ee ee ee oe or amweamwea= a a @@ a= a= 


MVS/SP JES2 
L Sa S bs Leek. 
CFMID HJE2329) 


MVS/SP JES2 
1.3.4 7 2.1.2 
CFMID HJE2330) 


| | 

| | 

| | 

| | 

| | 

| | 
MVS/SP JES3 | MVS/SP JES3 | 
1.3.17 2.1.1 | 1.3.4 7 2.1.2 
CFMID HJS2327) | (FMID HJS2329) | 
| | 

| | 

| | 

| | 

| | 

| | 


iT 
Wl 
iT 
Vv 


VM/SP or VM/HPO 
Release 4 with 


VM/SP or VM/HPO 
Release 5 with 


RSCS 2.1 RSCS 2.2 
(see note 2) Csee note 2) 
------- or --------| ------- or --------| 


Figure 
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B-3. Minimum system levels that support page mode data networking 


JES2 NJE 


Note 2: Earlier versions of RSCS can be used in conjunction with user-wntten 
“bridge” code. 


MVS/SP JES2 
1.3.4 7 2.1.2 
CFMID HJE2330) 


MVS/7SP JES2 
LieGed 7. 2.121 
CFMID HJE2329) 


| 

| MVS/SP JES2 

| 1.3.4 7 2.1.2 
| (FMID HJE2330) 


| 
| 
| 
| 
| 
| 
MVS/SP JES3 | MVS/SP JES3 
L307 2212 7 1.3.1. 752.1.) 
| 
| 
| 
| 
| 
| 
| 
| 


CFMID HJS2327) 


| 

| 

| MVS/SP JES3 
| 1.3.4 7 2.1.2 
| 
| 


CFMID HJS2329) CFMID HJS2329) 


VM/“SP or VM/HPO 
Release 5 with 


VM/SP or VM/HPO 
Release 4 with 


| 

[ VM/SP or VM/HPO 
| Release 5 with 
| RSCS 2.2 
| 


RSCS 2.2 RSCS 2.1 
AND PSF/VM AND PSF/VM 
(see note 3) (see note 3) 
------ or --------| m-—-—--- or -------- |------- or -------- 


| 
| VSE/POWER 2.2 
| (See Note 4) 


Figure B-4. Minimum system levels required to support networking of PAGEDEF and FORMDEF names 


Note 3: As described in the section entitled “VM special case 1,” it is possible to 
write a REXX EXEC for use with VM Release 5 instead of using PSF/VM to 
store the PAGEDEF/FORMDEEF names in the new control block. 


Note 4: At least one user has been able to use VSE as a receiving node for 
PAGEDEF and FORMDEF names passed from MVS. The sender specified 
FORMS = xxxx on the OUTPUT statement. This was considered by VSE to be 
an FNO= keyword, and was used to point to a printer parameter member, 
which specified the desired PAGEDEF and FORMDEF name. 
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The JES2 component of MVS/SP JES2 2.1.5 (FMID HJE2215) and of MVS/SP 
JES2 1.3.6 (FMID HJE1367) changed the lengths of the RPL and IOB prefixes 
to JES2 teleprocessing buffers, thus changing the length of optimum buffer sizes 
for virtual storage usage. This flash updates previous flashes on this topic by 
incorporating best sizes for the JES2/2.1.5 environment. 


This article was originally published as Washington Systems Center Flash 8608.3 
and INFO/MVS item G21301. It was reprinted with minor updates in the 
appendix of JES2 2./.5 Virtual Storage Tuning Guidelines GG66-0257 by Scott 
Wood. 


JES2 keeps a pool of teleprocessing buffers for RJE and NJE, which are used for 
both SNA and BSC transmissions. The size of the pool is based on the JES2 
initialization parameters TPDEF BUFNUM= (number of TP buffers) and 
TPDEF BUFSIZE= (TP buffer size.) If a large number of teleprocessing 
buffers are specified, care should be taken in selecting the buffer size to prevent 
excessive virtual storage fragmentation. 


The actual buffers in JES2 memory are prefixed with an RPL or IOB and associ- 
ated JES2 data so they are (TPDEF BUFSIZE= + (RPL or IOB) + JES2 
data) bytes long? and will not span a 4K page boundary. Therefore, the size of 
the buffer pool is equal to the number of 4K pages (each holding an integral 
number of buffers) required to hold the total number (TPDEF BUFNUM=) of 
buffers. If TPDEF BUFSIZE = is not adjusted to account for the RPL or IOB 
size plus associated JES2 data, excessive storage may be wasted in a large JES2 
RJE/NJE network. 


See the example in Figure B-5 on page B-13 with TPDEF BUFSIZE= 2000 and 
TPDEF MBUFSIZE = 400. 


2 The fix for APAR 0265765 on PUT 8303 (for all levels of JES2) increased the size 
of the JES2 RPL data at the front of SNA TP buffers by 16 bytes. The fix for 
APAR OZ79522, incorporated in JES2/2.1.5, and other changes in JES2/'2.1.5, 
changed the size of JES2 RPL data for SNA buffers from 208 bytes to 252 bytes. 
In addition, the JES2 IOB prefix data for BSC buffers got lengthened from 120 to 
136 bytes in JES2/2.1.5. 


BSC Multi-leaving Buffer: 


TPDEF 
IOB| MBUFSIZE= | 
136|<-- 400 -->|< 


Figure B-5. Wasted Storage with Sample JES2 TP Buffer Sizes 


A better example is shown in Figure B-6 with TPDEF BUFSIZE= 1792 and 
TPDEF MBUFSIZE = 800. (Note that the parameter BUFSIZE=400 may be 
specified on the RMTnnnn initialization statement for those multi-leaving 
remotes which don’t have room for 800 byte buffers.) 


a a ne ae a ae eee ioe G096-byte ipage: oo 333535254555 45 4 4-SS SS > 
NJE SNA Buffer: 

RPL | TPDEF BUFSIZE= Waste| RPL | TPDEF BUFSIZE= Waste 
252|<3-4o5=-==— 1192. 22SsSss2 >| 4|252|<--------- 1792-S2>----->= >| 4 


NJE BSC or CTC Buffer: 


IOB| TPDEF BUFSIZE= Waste|IOB| | TPDEF BUFSIZE= Waste 
136 | <---------- 1792 ------- >|120|136 | <--------- 1792 ---------- >1120 


RJE BSC Buffer: 


TPDEF TPDEF 

MBUFSIZE= MBUFSIZE= 
IOB| or BUFSIZE= | Wasted {IOB| or BUFSIZE= | Wasted 
136|<--- 800 --->|<--- 1112 ---->|136|<--- 800 --->|<---- 1112 ----- > 


Figure B-6. A better choice of JES2 TP Buffer Sizes. Very little wasted space for SNA or NJE; less than previous 
waste for RJE BSC. 


More specifically, the buffer pool size is determined by the following logic: 


1. The value specified in the TPDEF BUFSIZE = initialization parameter may 
not be the actual value used by JES2. It is rounded up to the larger of: 


TPDEF BUFSIZE=, 

TPDEF MBUFSIZE=, 

largest BUFSIZE on the RMTnnnn statements, 
280 if NJEDEF LINENUM = is greater than 0, 


and finally rounded up to a multiple of 8. 
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2. Each data buffer in JES2 memory has an RPL prefix for SNA transmissions 
or an IOB prefix for BSC transmissions. Therefore, the greater of the fol- 
lowing (guess which wins) 1s added to the adjusted TPDEF BUFSIZE= for 
the storage requirements of all TP buffers: 


e RPL plus associated JES2 data size (252 bytes for JES2 2.1.5/systems) 
e JOB plus associated JES2 data size (136 bytes for JES2/2.1.5 systems) 
(This is true even if no JES2 SNA lines are defined to JES2.) 


3. The above sum is rounded up to a multiple of 8. If the result is over 4096, 
then 4096 is used. 


4. The resultant value for TP buffer size including prefix is then divided into 
4096 to determine the number of integral buffers per page. 


5. Then the number of pages required for TPDEF BUFNUM= buffers is cal- 
culated and a GETMAIN 1s issued to obtain the memory. 


The ‘usable’ TP buffer size is finally calculated by subtracting the prefix areas 
(RPL for SNA, and IOB for BSC) back out. 


Figure B-7 shows some examples of buffer sizes for the JES2/2.1.5 environment. 


TPDEF Number of Data utiliz'n Comment 
BUFSIZE buffers 


Maximum 


Optimum 


Optimum 


Optimum 


Optimum 


Figure B-7. Optimum TPDEF BUFSIZE Values. Prefix sizes used are JES2/2.1.5 values. 


To calculate optimum values for TPDEF BUFSIZE= for other numbers of 
buffers per page, use the following formula: 


optimum BUFSIZE = (€€€4096 - (n ®¥ vd) 7 nd) 7 8 ) ® 8B 
where ’n’ is the number of buffers per page you want, and where ‘v’ 1s: 


e 252 for an SNA or mixed SNA and BSC JES2/2.1.5 environment, 
e 136 for a pure BSC JES2/2.1.5 environment 


The actual transmission data buffer size for the various TP devices is determined 
as follows: 
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NJE (SNA, BSC or CTC): The actual transmission data buffer size used 1s 
equal to the smaller of the TPDEF BUFSIZE= values for each of the two adja- 
cent nodes. This is calculated independently for each NJE session. 


RJE (SNA): The actual transmission data buffer size used is equal to the value 
specified by the BUFSIZE= parameter on the RMTnnnn initialization state- 
ment. Values of 128 up to a maximum of the “usable” TP buffer size as specified 
on the previous page are allowed. 256 is the default. Some devices, such as 
3770's, allow only 256 or 512. 


RJE (BSC Multi-Leaving): The actual transmission buffer size used is equal to 
the value specified by the BUFSIZE= parameter on the RMTnnnn initialization 
statement (TPDEF MBUFSIZE = 1s the default if not specified.) 


RJE (BSC Hardware): ‘The actual data transmission buffer size used is set 
according to the following device types: 


e 2770: 127, or 264 if BUFEX specified, or 520 if ABUFEX specified 


e 2780 (or 3740): 400 
e = 3780: 520 
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It is often convenient to keep several JES2 jobs in a single CMS file. This can 
simplify maintenance and documentation of logically related jobs (e.g., month 
end closing). 


Spooling such a file to RSCS for transmission across an NJE link is a violation 
of NJE protocols. Only one job may be represented by a single job 
header-data-job trailer sequence. When the file is received at a JES2 system the 
results are unpredictable. 


The solution to this problem is to spool each job to RSCS separately, so 
that each job is properly “wrapped” in a NJE header and trailer. This can be 
accomplished manually, by a program or an EXEC. 


Logic Flow: Whichever method is used, the logic flow is: 


READ INPUT FILE RECORD 
IF NOT JOB CARD THEN ABORT 7% FIRST CARD ISN'T A 


JOB CARD - ERROR X/ 
DO UNTIL END-OF-FILE 
DO UNTIL RECORD READ IS JOB CARD 


WRITE WORK FILE RECORD 
READ INPUT FILE RECORD 
END 
PUNCH WORK FILE TO RSCS 
END 


Figure B-8. Logic Flow for Punching Separate Jobs from a CMS File 


The decision to use an EXEC, XEDIT macro or a program should be based on 
ease of implementation and execution time considerations. If the job-streams are 
small and/or infrequent, the EXEC is easier to implement. On the other hand, a 
program will run faster. 


XEDIT Structure: The following XEDIT macro is intended only as an example 
- not as executable code. 


The macro should position on the first (or only) JOB card and then use subse- 
quent JOB cards or end of file to tngger punching that portion of the file to 
RSCS. 


*% ACTIVATE THE DON'T CARE CHAR 
SET ARBCHAR ON $ 

ERASE WORK FILE G 

L,//$ JOB , 

* NO JOB CARD FOUND 

&IF &RC NE 0 &GOTO -El 

=Ld 

PUT ,77$ JOB , WORK FILE G 

IF &RC NE 0 &GOTO -L2 

* THIS EXEC WOULD SPOOL, TAG AND PUNCH 
* ACCORDING TO LOCAL CONVENTIONS 
EX PUNX 

&GOTO -L1l 

-L2 

* PUNCH THE LAST JOB 

&IF &RC EQ EOF EX PUNX 

& EXIT 

=El 

&TYPE NO JOBCARD FOUND 


Figure B-9. XEDIT Macro to Punch Separate Jobs from a CMS File 


Program Structure: A program for this purpose could use the CMS file system 
or the OS simulation macros. Its structure would be very similar to the logic 
flow shown above. The DIAGNOSE instruction could be used to issue the 
spool, TAG and PUNCH commands. 
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In initiating an NJE session there are two different techniques used at the VTAM 
API: 


1. OPNDST OPTCD=ACQUIRE 


2. SIMLOGON followed by OPNDST OPTCD= ACCEPT from the LOGON 
exit 


JES2 and POWER use technique !. BDT (JES3) and RSCS use technique 2. 
Number 2 can be used by a single NJE application, allowing the system pro- 
grammer or the operator to specify whether the node should be PLU or SLU on 
each connection pair. This is helpful in limiting the number of log mode images 
that must be maintained in each of the VTAM libranes. I think you will see why 
this may be a problem in large networks after you digest the remainder of this 
document. 


Following are the SNA RU flows generated by each of these techniques. Note 
that in all cases a “bind image” flows from the SLU VTAM to the PLU VTAM 
and the final BIND always flows from the PLU to the SLU’s SCIP exit, through 
both VTAMs. OPNDST ACQ does not permit the PLU to see and modify or 
use values from the bind image which onginates from the logmode table libraries 
(VTAMLIB) at the SLU’s node. This is OK for most BIND parameters that can 
be predefined at the PLU. It is not true for the pacing values. This will be 
described following the diagrams. (ILU stands for Initiating LU in the diagrams). 


NJE VTAM 1 
NODE1 


OPNDST — CDINIT (ILU=PLU) > 
ACQ 
+ <—— CDINIT RSP (COS Name) — 
Bind 
<—— CDCINIT (BIND Image )—— 


———BIND (Non—-Neg) > >SCIP Exit 


OPNDST< < + RSP ——_____———_ <————OPNSEC 
Exit 
This side is This side is 
PLU SLU 


Figure B-10. SNA Session Initialization (OPNDST ACQ) 


Pacing in the Bind Image 


—— CDINIT 
(ILU=PLU, Modename ) 


<— CDINIT RSP (COS Name) — 


LOGON EX<-CINIT— <—— CDCINIT (BIND Image ) — 


Modi fy 
Bind 


OPNDST (ACC J——> BIND (Non—Neg ) >SCIP Exit 


OPNDST< + RSP —_— <————_OPNSEC 
Exit 
This side is This side is 
PLU SLU 


Figure B-11. SNA Session Initialization (SIMLOGON) 


The first RU to flow between two systems as a part of session establishment is 
the CDINIT RU. It specifies whether the origin node wishes to be the PLU or 
the SLU. For NJE protocols it will always specify the origin wishes to be PLU 
(ILU= PLU). With this form it will carry a logon mode name if one was pro- 
vided by the origin NJE application. The CDINIT RSP RU is an extended 
response and will carry the COS name found in the selected (specific or default) 
logon mode image at the future SLU. The COS entry used for the route and pn- 
ority selection for the new session will always be found at the PLU. 


The CDCINIT RU always flows from SLU to PLU and will carry the BIND 
image from the selected or defaulted logon mode image at the SLU. This image 
can be seen by the PLU application when its LOGON exit is entered by issuing 
INQUIRE SESSPARMS. 


Note that if the PLU issues INQUIRE SESSPARMS before the CDINIT and 
CDCINIT flow VTAM will present a logmode image from the libranes at the 
PLU. This is not the image that will later be used when OPDST ACQ 1s issued. 
If the NIB contains a logmode name when this INQUIRE is issued, that umage 
will be selected at the PLU. If no logmode name is in the NIB a default mmage 
will be selected at the PLU. 


VTAM pacing involves four counts 


PS - PLU send 
SR - SLU receive 
SS - SLU send 


PR - PLU receive 


All these fields are in the final bind image but the final setting that flows is a 
result of complex algorithms that look at: 


1. The values for three of these fields in the selected logmode image at the 


SLU’s VTAM libraries. These values were established by system program- 
mers using batch assembler runs with VIAM macros MODETAB, 
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Pacing Selection Algorithms 
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MODEENT and MODEEND. The three pacing values that can be defined 
are PS (PSNDPAC), SR (SRCVPAC) and SS (SSNDPAC). PR is not 
definable because VITAM does not support two stage pacing for the SLU to 
PLU flow. Two stage pacing is only supported for PLU to SLU flow and 
only if the SLU is in a PU_1 or 2 node. One stage paging is always used for 
NJE, both directions. 


The VPACING value in the VTAM APPL statement for the SLU 


The VPACING and AUTH=NVPACE parameters on the VTAM APPL 
statement for the PLU 


The bind image prepared by the PLU application and pointed to by 
OPNDST 


Lastly, the SLU VTAM uses its configuration knowledge about the type of 
PU that the SLU is in. For NJE the SLU VTAM will always set bit 0 of 
bytes 8 and 12 to one stage pacing both directions in the CDINIT bind 
image. This will force PS=SR and SS=PR when all the other merging is 
done. If the PLU tnies to set these bits as they are currently doing, VTAM 
ignores them. 


For the following discussion a pacing count of 0 means “no pacing” by VTAM. 


PS=SR=? 


I: 


2: 


3. 


Use zero if PLU APPL AUTH = NVPACE 
Else use SRCVPAC value if it is not zero 


Else use SLU VPACING value. Note, if not coded on APPL statement, 
default is zero and that becomes PS = SR=0 


Note, the PLU application cannot effect these two values, even if it tries. 


SS=PR=? 


I. 


2. 


Use zero if SSNDPAC value is zero 


Else use PLU VPACING value. Note same default of zero as for SLU 
VPACING 


PLU built bind image may REDUCE value but not to zero. 


Note the only pacing value that NJE code can effect is the pacing from SLU 
to PLU. 


BIND Image 


Implications 


Offsets 8, 9, 12 and 13 in the BIND image are properly defined as follows: 
BYTE Bits Value Definition 


8 0-1 Set by the SLU VTAM. For NJE 
always set to one stage pacing 
for SLU to PLU flow which forces 
SS=PR 


2-7 B*bbbbbb'* Secondary Send pacing count 
Set by VTAM equal to Primary 
Receive pacing count. 


0-1 Reserved 

2-7 B‘'bbbbbb* Secondary Receive pacing count 

Set by VTAM from merge of 
AUTH=NVPACE on PLU APPL statement 
and SRCVPAC in logmode image at 
SLU and VPACE on SLU APPL statement. 
Not affected by PLU BIND image 


12 0-1 Set by the SLU VTAM. For NJE 
always set to one stage pacing 
for PLU to SLU flow which forces 
PS=SR 


2-7 B‘'bbbbbb'* Primary Send pacing count 
Set by VTAM equal to Secondary 
Receive pacing count. 


13 Reserved 


0-1 

2-7 B*bbbbbb! Primary Receive pacing count 

Set by VTAM from merge of SSNDPAC 
in logmode image at SLU and VPACE 
on PLU APPL statement. PLU can 
only reduce resulting value but 
not to zero. 


Note that VWITAM simply ignores whatever the PLU sets in the BIND image 
except for the Primary Receive pacing count. 


NJE sessions should always be paced otherwise severe storage problems may 
occur at the receiving nodes, which can be both ends since NJE 1s full duplex. 
The above algorithms can result in a pacing count of 0 in one direction or the 
other by improper APPL statements or log mode entry selection. The NJE apphi- 
cations can not override a zero count by bind image modification. 


Only the SLU can see the final results of the selections. A pacing count of zero in 


either direction can cause severe performance problems. 
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Adding User Sections to NJE Headers (JES2) 


This is an update to WSC FLASH 8344 for MVS/SP - JES2 Versions 1.3.6 and 
2.1.5. (Comments have been added in the source code of recent versions of JES2 
(2.2.0) to help show where to place these modifications.) It provides an explana- 
tion for users to create user sections in the following NJE records: 


e Network Job Header (‘NJH’) 
e Network Job Trailer ((NJT’) 
e Network Data Set Header (‘NDH’) 


The job headers and trailers are kept with each job and any SYSOUT data sets 
throughout the life of the job or data set and transmitted form node to node. See 
the figure below showing the flow of these records. 


JOB JOB IN-STREAM| DD |JCL |JOB JOB 
TRANSMITTER ===>] TRAILER DATA * CARD | CARD | HEADER | ===> JOB 
DATA RECEIVER 
SYSOUT JOB DATA JOB 
TRANSMITTER ===>/TRAILER| SYSOUT DATA SET | —SET |HEADER| ===> SYSOUT 
HEADER RECEIVER 


Figure 1. Job and SYSOUT Flow 


The design of these records provides for user sections to be added. The changes 
listed here should help the user create the desired user sections; the installation 
must also add logic to JES2 to store and/or retrieve the required data in the new 
sections. 


In order to understand the changes required to implement user sections, a short 
explanation of the network headers is necessary along with a descnption of JES2 
processing in the RNJEHDTR routine. (The routine logic has not changed since 
the first release of JES2/NJE, but is added to this update to better explain the 
changes required.) 


Network Headers - an Overview 
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A header is composed of multiple ‘sections’: a general section, which is common 
across all networking products, and optional product specific sections. For 
example, job headers which onginate on a JES2 node also contain a JES2 
section. Each section 1s preceded by a length field. To ensure compatibility across 
various versions of the headers, any new fields are always added to the end of a 
section. 


If a new field is added, the section length is increased by the length of the new 
field. Using this length, JES2 (or any NJE product) can recognize a down-level 
section by comparing the length of the section which is received to the length 
which is required by this system. If the received section is shorter, the section is 
expanded (padded with binary zeros) to the required length. This section expan- 
sion allows further JES2 processing to be transparent to down-level headers. See 
the figure below showing the basic structure of these records. 


<— 2 BYTES —>|<-1 BYTE->|<-1 BYTE-> 
a 


—— 
LENGTH OF FLAGS TRANSM 'SN 
JOB HEADER SEQ. ID 
$¢-—$——$S 
+——_.. nn " (-- + 
LENGTH OF SECTION— MODIFIER 
ID=X‘0O0' =x‘'OO' 


GENERAL SECTION 
———— 


GENERAL SECTION 


— SS} 
$$$ $$ 
LENGTH OF SECTION— | MODIFIER 
JES2 SECTION | ID=X'84' =x '84' 

+ OOO +t 
JES 2 SECTION 
+——__—_—_.?” _=—_ PPS OO SSS See} + 
+ — — +—- — — —+t+ — — — + 

| LENGTH OF SECT. ID | MODIFIER 
USER SECTION | =B'll... | 
-—- — — -—- — — —+ — — — + 
| USER (INSTALLATION) CODE | 
- — — el tH — — Yt H 
USER SECTION | 
-—- — — lh +— — — —+ — — — + 


Figure 2. General Format of the Network Headers 


Note that an unmodified JES2 system will pass a job through which contains any 
number of user-defined sections in the Job Header, Job Trailer, or SYSOUT 
Header. Any received user-defined sections will be re-transmitted without change; 
however the changes listed in this document must be made if a user-defined 
section 1s to be CREATED on a JES2 system. 


Note also the following restrictions on lengths of headers and trailers: 


e The JI:S2 Job Control Table (JCT), the Job Header, and the Job Trailer are 
stored (contiguously) in the same spool buffer; therefore, the maximum 
lengths of the Job Header and Job Trailer (including all user sections) are 
restricted to the amount of spacc left in the spool buffer after the JCT is con- 
structed. On systems with 3992-byte buffers, this may not be a practical 
problem. 


e Data Set Headers (including all user sections) may not span a spool buffer 
(usually set to 3992 bytes). Additional buffers may be used to spool multiple 
headers, if necessary. 


As always, there is no guarantee that the modifications will work on all JES2 
systems; users should evaluate this change for applicability in their environment. 
Also, no work has been done to determine what effect these changes will have on 
other NJE systems such as RSCS, JES3, and VSE/Power Networking. 
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The RNJEHDTR routine in HASPRDR is used by both job receivers and input 
devices to process network job headers and job trailers. All processing in this 
routine is based on two explicitly-coded tables, RNJHTABL and RNJTTABL, 
which are explained in the source of HASPRDR. 


The job receiver uses the RNJEHDTR routine to process job headers and job 
trailers which are received from a network link or loaded from an offload data set. 
Each header section is moved from the transmission buffer into the JCT buffer. 
Using the control tables, each header section is expanded to the length required 
by this system. The control tables are also used to set defaults for any sections 
which are not found in the received header or trailer. 


The input processor uses the RNJEHDTR routine and the control tables to 
build a default job header and trailer for each job which enters through a local, 
RJE or internal reader. 


Job Receiver Processing: The network job receiver invokes this routine when 
either a job header or job trailer has been received across a network link. This 
routine is also used by spool offload job receivers when loading from an offload 
data set. For the job header, this routine is called from the job card scan routine 
in HASPRDR. For the job trailer, this routine is invoked from processor termi- 
nation. 


The header or trailer is received in 256-byte segments through the SEXTP GET 
interface. The input to RNJEHDTR 1s the first segment of the header or trailer. 
If necessary, this routine internally issues $EXTP GET requests for additional 
header segments. 


The RNJEHDTR logic for job receivers is as follows: 
e Call the RNJHINIT subroutine for the first header segment. 
e For each header section: 


— Loop through the approp~*te control table (RNJHTABL or 
RNJTTABL), looking for an entry which matches this section’s identifier 
and modifier. If a matching entry is found, use the corresponding section 
length (+ 0) as the minimum length for this section. If there is no 
match, use the received section length as the minimum length. 


— If this is not the first table entry (the general section), OR’ the section 
flag byte (+ 4) into a work area (RNJHSECS). 


— Call the RNJHMOVS subroutine to move the header section to the JCT 
buffer. 


e When all header sections have been moved into the JCT buffer, the work 
area indicates which sections were moved. Compare the work area to the first 
table entry to determine which sections remain to be built. Loop through the 
control table again to build defaults in the JCT buffer for the remaining 
header sections. 


The following two subroutines are used by the RNJEHDTR routine: 


RNJHINIT - This subroutine checks to make sure that this segment of the 
header fits into the remaining space in the JCT buffer. If the header does not 
fit, the HASP121 ‘ERROR READING JOB HEADER OR TRAILER’ 
message is issued. This routine also checks the transmission sequence indi- 
cator for this header segment (NJHSEQ or NJTSEQ in $NHD). 


RNJHMOVS - This subroutine moves the header section to the JCT buffer. 
If necessary, the section is automatically expanded (with binary zeros) to the 
minimum length. This subroutine also handles segmented headers, using the 
$EXTP GET interface to obtain another header segment. 


Input Processing: The input processor uses RNJEHDTR to build the job 
header and job trailer for jobs which enter the system through local, RJE or 
internal readers. This routine is called from the job card scan routine for job 
headers and from processor termination for job trailers. 


The RNJEHDTR logic for the input processor is as follows: 


Skip building the general section. The general sections for both the job 
header and job trailer are built in the job card scan routine before 
RNJEHDTR is called. 


Using the appropriate control table (RNJHTABL or RNJTTABL), loop 
through the table entries. Build default header sections in the JCT buffer, 
using the section length, type and modifier from the table entry. Note that a 
separate section is created for each entry in the control table. 


Adding User Sections to the Job Header 


Adding user section(s) to the Job Header requires source changes to the $NHD 
macro and the HASPRDR module. 


Changes to SNHD (Network Job Header DSECT) 


This macro contains the DSECTs fo. .he following three network control blocks: 
Job Header, Job Trailer and Data Set Header. The appropniate headers must be 
redefined and all JES2 source modules which reference the NJH DSECT must be 
re-assembled. 


I. 


2. 


Change the NJHLLEN EQUate to include NJHULLEN in the total length. 


(OPTIONAL) The user section identifier field NJHUTYPE 1s currently set 
to NTYPUSER, but should be changed if more than one type of user section 
is to be defined or exist in the Job Header. The first two bits must be B’11’; 
the other six bits may be set to any value and are used to uniquely define the 
type of user section. This value is also used by the Job Trailer and Data Set 
Header user sections (see below). 


(OPTIONAL) The user section modifier field NJHUSMOD is used to 
further distinguish between different modification levels of the same type of 
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Changes to HASPRDR 


user section. The installation needs to change this value only if more than 
one user section of the same type (NJHUTYPE) 1s desired. 


(OPTIONAL) The NJHUCODE field may be used to uniquely define the 
origin of the user section in a network with multiple enterprises. This word 
may be set to any value desired by the installation. It is suggested that the 
SHARE/GUIDE installation code be used as a identifier unique to each 
installation. (Changing this DSECT is not really necessary; the field must be 
initialized to this value by code in HASPRDR to be effective.) 


Insert additional fields required in the user section between the labels 
‘NJHUCODE’ and ‘NJHUEND’. Space will be reserved in the user’s 
section for these defined fields and will be set to binary zeros on the input 
systems. 


First, a table must be modified to allow the changes to the Job Header DSECT 
(see above) to be built for jobs entering this system. Next, after the user section 1s 
built, the appropriate fields in the user section must be filled in. (Don’t forget to 
fill in the NJHUCODE field - see above.) 


The spool offload section must be the last section, so the user section must be 
inserted before it. 


i 


To create a user section, the section flag byte at RNJHTABL+4 must be 
changed to B’11110000’. This turns on the forth bit in the section flag byte 
to match the ‘OR’-sum of the entnes which follow it. 


The user section entry must be added between entnes RHDRTAB2 and 
RHDRTABS 


RHDRTABU DC AL2CNJHUEND-NJHU),ALIONTYPUSER,NJHUSMOD) 
DC B‘'00100000',AL1(0) USER SECTION 


The Section Flag Byte of the Spool Offload Section (RHDRTABS + 4) must 
be changed to indicate that it is the forth section: B’00010000’. 


Adding User Sections to the Job Trailer 


Adding user section(s) to the Job Trailer requires source changes to the $NHD 
macro and the HASPRDR module, which are very similar to the changes for the 


Job Header. 


Changes to SNHD (Network Job Trailer DSECT) 
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This macro contains the DSECTs for the Job Header, Job Trailer and Data Set 


Header. The job trailer must be redefined and all JES2 source modules which 


l. 


reference the NJT DSECT must be re-assembled. 


Change the NJTLLEN EQUate to include the length of the user section 
NJTULLEN. 


2. (OPTIONAL) The user section identifier field NJTUTYPE 1s currently set to 
NTYPUSER, but should be changed if more than one type of user section 1s 
to be defined or exist in the Job Trailer. 


3. (OPTIONAL) The user section modifier field NJTU$MOD is used to further 
distinguish between different modification levels of the same type of user 
section. The installation needs to change this value only if more than one 
user section of the same type (NJTUTYPE) 1s desired. 


4. (OPTIONAL) The NJTUCODE field may be used to uniquely define the 
ongin of the user section in a network with multiple installations. (Changing 
this DSECT is not really necessary; the field must be initialized to this value 
in HASPRDR to be effective.) 


5. Insert additional fields required in the user section between labels 
‘“NJTUCODE’ and “NJTUEND’. Space will be reserved in the user’s section 
for these defined fields and will be set to binary zeros on the input systems. 


Changes to HASPRDR 


Again, the ‘Contents Control Table’ must be modified to allow the changes to 
the Job Trailer DSECT to be built for jobs entering this system. After the section 
is built, the various fields must be filled in with the appropnate information. 
(Don't forget to fill in the NJTUCODE field.) 


The spool offload section must be the last section, so the user section must be 
inserted before it. 


1. ‘To create a user section, the section flag byte at RNJTTABL+4 must be 
changed to B’11100000’. This turns on the third bit in the section flag byte 
to match the ‘OR’-sum of the entries which follow it. 


2. The user section entry must be added between labels RNJTTAB1 and 
RNJTTAB2: 


RNJTTABU DC AL2(NJTUEND-NJTU),ALICNTYPUSER,NJTUSMOD) 
DC B*'01000000',AL1(C0) USER SECTION 


3. The Section Flag Byte of the Spool Offload Section (RNJTTAB2+ 4) must 
be changed to indicate that it 1s the third section: B’00100000’. 


4. The length of the user section (NJTULEN) must be set as the other sections 
are near label RNTRL. 


Adding User Sections to the Data Set Header 
Adding user section(s) to the Data Set Header requires different source code 


modifications than those required for adding user sections to Job Headers and 
Trailers. Changes are to the $NHD macro and the HASPNET module. 
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Changes to SNHD (Network Data Set Header DSECT) 


This macro contains the DSECTs for the Job Header, Job Trailer and Data Set 
Header. The data set header must be redefined and all JES2 source modules 
which reference the NDH DSECT must be re-assembled. 


Unlike the Job Header and Trailer, ¢ach section of the Data Set Header is built 
dynamically and the length of the entire block is computed as each section 1s 
added. 


1. Move the NDHLLEN EQUate beyond the user section so that it follows the 
NDHUEND label. This equate is used to define the length of the entire job 
trailer and fill in the first two bytes of the trailer. 


2. (OPTIONAL) The user section identifier field NDHUTYPE is currently set 
to NT'YPUSER, but should be changed if more than one type of user section 
is to be defined or exist in the Data Set Header. 


3. (OPTIONAL) The user section modifier field NDHUSMOD is used to 
further distinguish between different modification levels of the same type of 
user section. The installation needs to change this value only if more than 
one user section of the same type (NDHUTYPE) is desired. 


4. (OPTIONAL) The NDHUCODE field may be used to uniquely define the 
origin of the user section in a network with multiple installations. (Changing 
this DSECT is not really necessary; the field must be initialized to this value 
in HASPNET to be effective.) 


5S. Imsert additional fields required in the user section between labels 
‘NDHUCODE’ and ‘NDHUEND’. Space will be reserved in the user’s 
section for these defined fields and will be set to binary zeros on the input 
systems. 


Changes to HASPNET (Network SYSOUT Transmitter) 
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The various sections of the data set header are built with straight-forward code in 
the SYSOUT Transmitter as opposed tr the technique used in HASPRDR with 
the “Contents Control Table’. 


At label NSTDSHP, before the header is transmitted, code must be added (after 
the label, but before the Load instruction) to build the user section, update the 
total length of the data set header and fill in the fields. The technique used in 
creating the 3800 section at label NSTBLDA can be copied. Specifically, the fol- 
lowing steps should be taken: 


Clear User Section to zeros or default values. 

Set length of the User Section (NDHULEN). 

Update total Data Set Header length (NDHLEN). 

Indicate User Section/Modifier (NDHUTYPE/NDHUMOD). 
Move SHARE/GUIDE Installation Code (NDHUCODE). 
Store information in other user fields as required. 

Update the length of the Data Set Header (NDHLEN). 


PON ee 


Using OS Utilities to Send Bulk Data 


Much like the BDT IUP, utilities such as IEHMOVE may be used to unload 
MVS data sets, but is a bit more cumbersome than BDT. Other MVS utilities 
may be used to transmit VSAM (IDCAMS) and ISAM (IEBISAM) data sets by 
themselves, or with the BDT TUP. The basic technique is to convert the data set 
into 80-character logical records and send them as a SYSIN data set in a job 
which can rebuild the data set at the destination node. This technique can be a 
bit cumbersome in some cases, but can be done. 


I. 


Sequential, BDAM, or Partitioned Data Sets (any logical record length) 


a. 


b. 


Use IEHMOVE to unload (this must be to tape) 
Use IEBGENER to copy back to disk 


Use IEBGENER to concatenate the following JCL to the unloaded copy 
on disk and write it to an internal reader. 


1) JOB card, 

2) /*XEQ card 

3) An IEBGENER step to copy the following data to tape. 

4) The unloaded copy of the data set on disk. 

5) An IEHMOVE step to load it back to disk (need volume senal 
numbers). 


See the example below. 


ISAM Data Sets 


Use IEBISAM to unload it to a temporary disk data set 


Use IEBGENER to concatenate the following JCL to the unloaded data 
set and write it to the internal reader. 


1) JOB card, 

2) /*XEQ card 

3) An IEBISAM step to rebuild the ISAM data set 
4) The unloaded data set. 


VSAM Data Sets 


Use Access Method Services (REPRO) to create a sequential copy of the 
data set. 


Use IEHMOVE to unload the sequential copy (this must be to tape) 
Use IEBGENER to copy back to disk 


Use IEBGENER to concatenate the following JCL to the unloaded copy 
on disk and wnite it to an internal reader. 


1) JOB card 
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/7SENDPDS JOB 
/7UNLOAD EXEC 
//SYSPRINT DD 
//SYSUT1 DD 
//DD1 DD 
//DD2 DD 
/7TEMPOUT DD 
17 


// 
“/SYSIN DD 
COPY PDS= 


7% 
//TODISK EXEC 
/7SYSPRINT DD 
“/SYSUT1 DD 
iA 


// 
7/7 SYSUT2 DD 
// 


“/SYSIN DD 
7% 


//7SEND2 EXEC 
“7SYSPRINT DD 
7/SYSUT1 DD 
DD 
DD 
7/7 SYSUT2 DD 
“/SYSIN DD 


Figure B-12. Example 
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2) /*XEQ card 

3) IEBGENER step to copy to tape. 

4) The unloaded copy of the data set on disk. 

5) An IEHMOVE step to load it back to disk (need to specify volume 
senal number). 

6) An Access Method Services step to create a new VSAM data set and 
load it (using REPRO) from the sequential file on disk. 


< job parameters > 

PGM=IEHMOVE 

SYSOUT=* 

UNIT=3330,VOL=SER=WORK98, DISP=OLD 
UNIT=3330,VOL=SER=MVSRES, DISP=OLD 
UNIT=3330,VOL=SER=TSOSJL,DISP=OLD 
UNIT=3400-6,VOL=CPRIVATE,RETAIN, SER=T01557), 
LABEL=(€1,NL),DISP=C,PASS), 
DCB=CRECFM=FB, LRECL=80, BLKSIZE=800, DSORG=PS) 


x 
SYS1.LINKLIB, TO0=3400-6=1T01557,TODD=TEMPOUT, 
RENAME=LINKLIB2.UNLDPDS 


PGM=TEBGENER 

SYSOUT = 

DSN=LINKLIB2.UNLDPDS, DISP=OLD,UNIT=3400-6, 
VOL=CPRIVATE, SER=1T01557),LABEL=(1,NL), 
DCB=CRECFM=FB,LRECL=80, BLKSIZE=800, DSORG=PS) 
DSN=&UNLDPDS, DISP=C,PASS),UNIT=3330, 
DCB=CRECFM=FB,LRECL=80, BLKSIZE=800),SPACE=C(CYL,(1)) 
DUMMY 


PGM=IEBGENER 

SYSOUT=x 
DSN=SYS1.PROCLIB2C¢SENDJCL1),DISP=SHR 
DSN=&UNLDPDS, DISP=COLD,PASS),UNIT=3330 
DSN=SYS1.PROCLIB2(SENDJCL2),DISP=SHR 
SYSOUT=CA, INTRDR) 

DUMMY 


of Transmitting a PDS. Transmitting a copy of SYSI.LINKLIB (PDS) to NODE #2 


SENDJCL1: 


//RECEIVE JOB < job parameters > 

7¥XEQ NODE2 

4/SEND EXEC PGM=IEBGENER 

//SYSPRINT DD SYSOUT=* 

//SYSIN DD DUMMY 

//SYSUT2 DD DSN=UNLOADED.LINKLIB2, DISP=C(NEW, PASS),UNIT=3400-6, 
VOL=CPRIVATE, RETAIN, SER=101234),LABEL=C(1,NL), 
DCB=(RECFM=FB, LRECL=80, BLKSIZE=800) 

//SYSUTI1 DD xX 


SENDJCL2: 


//REBUILD EXEC PGM=IEHMOVE 
//7SYSPRINT DD SYSOUT=% 
//SYSUT1 DD UNIT=3330,VOL=SER=NORK99, DISP=OLD 
//DD1 DD UNIT=3330,VOL=SER=MVSRES, DISP=OLD 
//DD2 DD UNIT=3330,VOL=SER=WORK99, DISP=OLD 
//TAPEHOLD DD UNIT=3400-6, DISP=OLD, DSN=UNLOADED.LINKLIB2, 
7 VOL=CPRIVATE, SER=T01234),LABEL=(1,NL), 
17 DCB=(CRECFM=FB, LRECL=80, BLKSIZE=800) 
//SYSIN DD xX 
MOVE DSNAME=UNLOADED.LINKLIB2, TO=3330=WORK99I, FROM=3400-6=T01234,X 
FROMDD=TAPEHOLD, RENAME=SENT .LINKLIB2 
7% 


Figure B-13. Example of Receiving a PDS. Receiving a copy of SYSI1.LINKLIB at Node2. 
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Appendix D. Glossary 


This glossary defines NJE terms and other data 
processing terms used in this publication. For defi- 
nitions of terms not included in this glossary, see 
NJE Formats and Protocols, GG22-9373 and IBM 
Vocabulary for Data Processing, Telecommuni- 
cations, and Office Systems, GC20- 1699. 


ACF. Advanced Communication Facility - A 
group of SNA program products for users of MVS, 
VM and VSE that can provide improved data com- 
munication capability. 


ACF Networking. The use of Advanced Commu- 
nication Facility to exchange data between two or 
more processors using MSNF. 


ACF/VTAM. Advanced Communications 
Facility/Virtual Terminal Access Method 


ACK (or ACKO,ACK1). In BSC, an affirmative 
acknowledgement, indicating that the previous 
block was accepted without error, and the receiver 
is ready to accept the next block of transmission. 


adjacent. In NJE, two nodes are said to be “adja- 
cent” if they are connected directly by a communi- 
cation link or session. 


AFP. Advanced Function Pnnting 


AFPDS. Advanced Function Pnnting Data 
Stream. An architected set of control codes used to 
control page printers running in _all-points- 
addressable (1.e., page) mode. 


ASA. American Standards Association 


ASP. Attached Support Processor or Asymmetric 
Multiprocessing System - A system that provides 
supplementary job management, data management, 
and task management functions, such as: control of 
job flow, ordering of tasks and spooling. Prede- 
cessor of JES3. 


ASP Networking. The programming RPQ pro- 
viding NJE support for ASP 3.2.1 systems (SVS or 
MVT). 


BDT. Bulk Data Transfer - A Program Product 
for MVS (5665-302 and 5665-264). Also a 
Program Offering for MVS (5798-PKK). 


BIND. In SNA, a request to activate a session 
between two logical units. 


block control byte (BCB). A byte used to maintain 
the integrity of data during a multi-leaving trans- 
mission. 


BSC. Binary Synchronous Communication, or 
Bisynchronous Communication - Communication 
using binary synchronous line discipline in which 
transmission of binary-coded data between stations 
is synchronized by timing signal generated at the 
sending and receiving stations. 


bulk data. Collections of data in a file (VM) or 
data set (MVS or VSE). The term is used to differ- 
entiate from a transaction which is a smaller 
amount of data or a message. Also called “batch 
data”. 
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CES. See “connection event sequence”. 


channel to channel adapter (CTC or CTCA). A 
feature on S/370 channels that allows two 
processors to communicate directly to one another. 
It is described in JBM S/370 Special Feature 
Description: Channel-to-Channel Adapter, 
GA22-6983. Also see the IBM 3088. 


CMS. Conversational Monitor System - The 
interactive time-sharing facility available under 
VM/370. 


cold-start. The type of initialization of a system or 
subsystem that purges the queues upon starting. 


compaction. A method of reducing the length of 
records for transmission by representing certain 8 
bit characters with only 4 bits. Done by repres- 
enting adjacent “master” characters by a single byte. 
See JES2 Initialization and Tuning or N/E Formats 
and Protocols. 


compression. A method of reducing the length of 
records for transmission by removing blanks and 
duplicate characters. See N/E Formats and Proto- 
cols. 


connection. (in NJE) a physical link between two 
processors. It may consist of: 


one or more BSC lines 

a channel-to-channel adapter 
an SNA session 

(JES2 only) a shared spool 


connection event sequence (CES). A number in 
each path manager record, based on the current 
TOD clock value (in GMT), to prevent the use of 
redundant path manager records by the Network 
Path Manager. 


CPDS. Composed Page Data Stream. An old 
name for AFPDS. 


CTC. See “channel to channel adapter”. 
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data record. In NJE, this refers to all records with 
an RCB in the range 98-F8 and the range 99-F9 
which do not have an SRCB with the two high 
order bits set to one. 


data set header (NDH or DSH). An NJE control 
record that generally precedes a unit of SYSOUT 
data. It may also appear in the middle of SYSIN 
data to indicate a change in the format of the 
SYSIN data. 


DBCS. Double-Byte Character Set. A method of 
representing information, in which each character 
to be pnnted is represented by two bytes. This 
contrasts with EBCDIC, in which each character to 
be printed is represented by one byte. 


decompaction. The process of restonng a com- 
pacted record to its original form. 


decompression. The process of restoring a com- 
pressed record to its original form. 


DES. The National Bureau of Standards Data 
Encryption Standard - A cryptographic algonthm 
designed to encipher and decipher data using a 
64-bit key ‘specified in the Federal Information 
Processing Standard Publication 46, January 15, 
1977. : 


DLE. Data Link Escape - a BSC control character 
used to provide supplementary line control charac- 
ters. 


| 


end-node. A node in a NJE network which has 
only one connection to the network. It cannot act 
as an intermediate node, but can only receive jobs 
or sysout destined for itself. 


end of file (EOF). This refers to a null record that 
is transmitted at the end of a job, following the job 
trailer, to indicate that nothing remains to be trans- 
mitted. It 1s acknowledged by a Stream Complete. 


fan-out. The ability in NJE to send a SYSOUT 
data set to multiple destinations without sending 
multiple copies down the same link. 


file. A set of records related as a unit. Also 
referred to as a data set. 


FMH. See “function management header”. 


function management header (FMH). In SNA, 
specialized control format to select a destination 
and control the way data is sent or presented at the 
destination. 


GMT. Greenwich Mean Time - The standard 
global universal tume used as a common time refer- 
ence around the world. 


iH 


HASP. Houston Automatic Spooling Pnonity - A 
system that provides supplementary job manage- 
ment, data management, and task management 
functions, such as: control of job flow, ordering of 
tasks and spooling. Predecessor of JES2. 


HASP Networking. The programming RPQ pro- 
viding NJE support for HASP/SVS systems. 


host. A processor running OS (e.g., MVS, VSI, 
SVS) or VM having remote terminals attached. 


hybrid network. A NJE network with different 
systems (e.g., OS, VM, TSS) or subsystems (e.g., 
JES2, JES3) on different nodes. 


JCL. See “job control language”. 


JCT. In JES2, the Job Control Table - a spool- 
resident control block containing all the job-level 
information about the job. 


JECL. See “job entry control language”. 


JES. Job Entry Subsystem - A system facility for 
managing jobs and sysout data sets on auxiliary 
storage including spooling, job queueing and sched- 
uling. See also JES2 and JES3. 


JES2. Job Entry Subsystem/2 - A _ functional 
extension of HASP II program for MVS that 
receives jobs into the system and processes all 
sysout data produced by the job. 


JES3. Job Entry Subsystem/3 - A_ functional 
extension of ASP 3 program for MVS that receives 
jobs into the system, manages device allocation, 
setup, and processes all sysout data produced by 
the job. 


JES3 global. In a JES3 complex, the processor 
responsible for managing the complex, 1.e. Control- 
ling all input and output, insuring complex-wide 
data integrity, etc. The global also handles all net- 
working functions. 


JES3 local. A processor in a JES3 complex whose 
primary function is to run MVS jobs. Locals access 
the global for various services. 


job. The basic unit of transmission in a NJE 
network. It consists of all data beginning with a 
job header control record and ending with a job 
trailer control record. 


job control language (JCL). In OS/VS, an esoteric 
command language used to specify batch work. 


job entry control language (JECL). Specialized 
control language, interspersed in JCL, read by the 
job entry = subsystem (JES2, JES3, 9 or 
VSE/POWER). 


job header (NJH). The NJE control record that 


provides general information relating to the job as a 
whole. 
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job networking. Another name for network job 
entry (NJE). 


jobstream. Input to the system containing JCL 
and input data. May be one or more jobs. 
Usually in card image format. 


job trailer (NJT). The NJE control record the ter- 
minates the job and generally provides accounting 
information. 


link. A connection, or ability to communicate 
between two adjacent nodes. See link. 


logical unit (LU). In SNA, a port through which 
an end user or application accesses the network in 
order to communicate with another end user or 
application. 


logoff. (1) The process by which a user ends a ter- 
minal session. (2) In VTAM, a request that the 
terminal be disconnected from a VIAM applica- 
tion program. 


logon. (1) The process by which a user begins a 
terminal session. (2) In VTAM, a request that the 
terminal be connected to a VIAM application 
program. 


LU. Logical Unit - see LU. 

LRECL. Logical Record Length 

LU_0. Logical Unit Type 0. In SNA, a port 
through which two applications communicate using 


iumplementation-defined protocols. NJE uses such 
protocols for SNA transmissions. 


Miulti-Access Spool (MAS). Two to seven JES2 
systems sharing the input, execution, and output 
queues through the use of shared DASD. 


multi-leaving (ML). A _ pseudo-simultaneous bi- 
directional fully-synchronized multi-stream trans- 
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mission between two computers using BSC 
facilities. 


MSNF. Miulti-Systems Networking Facility - A 
feature of ACF/VTAM or ACF/TCAM that sup- 
ports communication among multiple host com- 
puters operating with VSE and MVS. 


MVS. Multiple Virtual Storage - an alternate 
name for OS/VS2. 


MVS/SP. Multiple Virtual Storage/System 
Product 
NAK. In BSC, a Negative Acknowledgement, 


indicating that the previous block was received in 
error, and the receiver is ready to accept a 
retransmission of the erroneous block. 


NCC. See “network connection control”. 


NCP. Network Control Program - A program, 
generated by the user from a library of 
IBM-supplied modules, that controls the oper- 
ations of a communications controller (3705). 


NDH. Network Data Set Header - see Data Set 
Header 


network connection control (NCC). An NJE 
control record used to establish or break a con- 
nection. Also used by the network path manager 
to send u.. rmation about other NJE connections. 


network. The assembly of equipment through 
which physical connections are made between 
remote locations. See also “NJE network” and 
“ACF Networking.” 


network job entry (NJE). (1) A facility for trans- 
mitting jobs (JCL and in-stream data sets), sysout 
data sets, (job-onented) operator commands and 
operator messages, and job accounting information 
from one computing system to another. (2) A 
facility that provides access to batch computing 
facilities from other host systems. It enables users 
to transfer work and data throughout a distributed 
network of batch computing facilities. (“NJE” is 
not a part of “Systems Network Architecture 


(SNA)’, but is an application layer which uses 
SNA, BSC and CTC transmission facilities.) (3) 
The JES2 program product implementation of the 
NJE Protocol. 


network job interface (NJI). The onginal HASP, 
RSCS, ASP, or JES3 Programming RPQ imple- 
mentation of the NJE Protocol. 


network path manager (NPM). A facility to 
manage the topology of a network through the 
sending, receiving and processing of network con- 
nection and control (NCC) records. It handles 


sign-ons, sign-offs, alternate path routing and par- 
allel links. 


NJE. See “network job entry”. 

NJH. Network Job Header - see “job header”. 
NJI. See “network job interface”. 

NJT. Network Job Trailer - see “job trailer’. 
NMR. See “nodal message record”. 


nodal message record (NMR). A record for trans- 
mitting commands and messages to other locations. 


node. The high-level addressable point in a NJE 
network. A processing point in a network. It can 
be either a single system (e.g., WM processor), or a 
collection of loosely-coupled systems (e.g., JES2 or 
JES3 complex) sharing a common job queue. 


nodeid. Node identifier. The name by which a 
node is known to users, operators and other nodes 
in the network. Also called nodename. It may 
also be a number (JES2 only). 


nodename. The one-to-eight character (EBCDIC) 
name assigned to a node by which a node is known 
to the rest of the network. 


non-switched line. A communication link between 
two devices or processors that does not have to be 
established by dialing. 


notification. The sending of a message to an inter- 
active user of an event associated with the proc- 


essing of a job. 


NPM. See “network path manager”. 
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page mode. A mode of pnnter operation in which 
the pnnter can accept a page of data at a time in 
all-points-addressable format. 


password. A one to eight alphameric character 
string that a user specifies to meet security require- 
ments when entering the system or accessing pro- 
tected data sets. 


path. A collection of connections through which 
jobs (and sysout data sets, commands & messages) 
flow from an originating node to a destination 
node. 


path management record. In NJE, a NCC add or 
subtract record containing network connectivity 
information. 


POWER. “’Pnrority Output Writers, Execution 
Processors and Input Readers” - a spooling sub- 
system for VSE systems 


PSF. Pmnnt Services Facility - a program product 
for MVS or VM to control advanced function 
pminters in all-points-addressable mode. 


R 


receiver cancel. In NJE, this refers to a record 
with an RCB of X’BO’. This is used after a Per- 
mission Granted has been transmitted and the 
receiver wishes to terminate the job on a stream. 


record. In NJE, this is defined as all bytes begin- 
ning with an RCB up to but not including the next 
RCB. This term encompasses Control Records, 
data records, and nodal message records. 


record identifier (RID). The Record Identifier used 
in SNA transmissions. It is a three byte field made 
up of the RCB, SRCB, and a byte containing the 
length of the data record. 


remote job entry (RJE). Facility for submitting a 
job, and receiving output, through an I/O device 


Appendix D. Glossary D-5 


that is connected to a computer via communi- 
cations equipment. 


remote terminal. A terminal attached to a host (or 
subhost) system through a data transmission link. 


request/response unit (RU). In SNA, an element 
of the Basic Link Unit containing data and data 
stream controls. 


RID. See “record identifier”. 
RJE. See “remote job entry”. 


RJP. Remote Job Processing. The ASP and 


JES3 name for RJE. 


routing. The assignment of a communication path 
by which a message (or other transmission) will 
reach its destination. 


RSCS. Remote Spooling Communications Sub- 
system - A virtual machine subsystem of VM/370 
that transfers spool files between VM/370 users, 
remote stations, and remote and local batch 
systems via HASP-compatible telecommunications 
facilities. 


RSCS Networking. The formal name of the 
program product (5664-188 for version 2) providing 
NJE support for VM/370 systems. 


RU. Request/Response Unit 


SAF. secunty authorization facility 
SCB. See “string control byte”. 


scheduler work block (SWB). A structured data 
block containing the data produced by subsystem 
JCL venfication and internal processing. 


SCIP. Set Control Interval Processing 
SDSF. System Display and Search Facility - a 
licensed program product (5665-488) that super- 


sedes the SPOOL Display and Search Facility 
program offering (5798-DWX). It allows end users 
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and operators to display job data from JES2 spool 
and to control selected JES2 operation in a full 
screen environment. 


SDLC. Synchronous Data Link Control - A pro- 
tocol defined by SNA used for data transmissions 
over common-carrier communication facilities. 


session. (in SNA) A formally bound pairing 
between two network addressable units. 


SMF. System Management Facility - A standard 
feature of OS/VS2 that collects a vanety of system 
and job related information. 


SNA. (1) (Noun) See “systems network architec- 
ture”. (2) (Adjective) Adhering to the Systems 
Network Architecture definitions. “SNA” 1s used to 
describe links, I/O devices, telecommunication con- 
trollers, etc. 


spool. Simultaneous Peripheral Operation On-Line 
(1) (Noun) An area of auxiliary storage defined to 
temporarily hold data during its transfer between 
peripheral equipment and the processor. (2) (Verb) 
To use auxiliary storage as a buffer storage to 
reduce processing delays when transferring data 
between peripheral equipment and the processing 
storage of a computer. 


spoolid. Spool file identifier. A number between 1 
and 9900 that is assigned to a spooled file by VM 
spooling facility. 


SRCB. See “sub record control byte”. 


store-and-forward. The protocol of completely 
storing a job (or sysout data set) at an intermediate 
node before forwarding it on to the next node in 
the path to its destination. 


stream. A logical flow of information. 


string control byte (SCB). A byte within the data 
stream that is used in compression algorithms. 


sub record control byte (SRCB). Defines indi- 
vidual types of records within an RCB. 


subhost. A system that can act like a host to its 
RJE terminals, but can also act as an RJE terminal 
to another host system through a workstation 
program. 


SUN. San Jose Unified Network or Subsystem 
Unified Network - An early implementation of 
NJE networking between IBM internal sites. Also 
called the IBM Corporate Job Network (CJN). 
Now called “VNET”. 


SWB. See “scheduler work block”. 


switched line. A communication link in which 
connection between two devices or processors is 


established by dialing. 


SYSIN. SYSIN refers to a type of job which is 
intended to be processed (or executed) by the oper- 
ating system at the receiving node. After processing, 
SYSOUT is usually produced which is usually 
returned to the origin node. It is possible for a job 
to execute and produce SYSIN to be executed at 
the same or another node. 


Also refers to in-stream data within a pre-execution 
job. 


SYSIN data. The in-stream data imbedded with 
JCL in a pre-execution job. 


SYSOUT. SYStem OUTput data which is 
SPOOLed by the job entry subsystem and eventu- 
ally de-SPOOLed and written to a card punch, 
printer or other output device. When received by 
the networking component at the destination, it is 
not inserted into the execution job queue. It may 
be printed or punched immediately on a locally 
connected output device, or placed into a state 
from which a user or operator of the system may 
specify its further processing. 


systems network architecture. A data communi- 
cations protocol for controlling a teleprocessing 
network through a formal definition of the func- 
tional responsibilities of communication system 
components. 


TCAM. Telecommunications Access Method - A 
teleprocessing access method used to transfer data 
between application programs and local or remote 
terminals. In the NJE context, only the version of 
ACF/TCAM which supports the VTAM interface 
is relevant. 


transmission block. A collection of one or more 
records to be transmitted over the network as a 
unit. Transmission blocks are that portion of each 
transmission that is independent of the access 
method. 


transmission buffer. An area in storage for building 
and receiving transmission blocks. 


TSO. Time Sharing Option - An option of MVS, 
SVS, and MVT that provides conversational time- 
sharing from remote terminals. 


TSO/E. Time Sharing Option/Extensions 


TSS. Time Sharing System/370 - A controlled 
marketing general purpose virtual memory oper- 
ating system. 


userid. User identifier. (1) (VM) the name by 
which a virtual machine and its user are known to 
others. (2) (MVS) the name by which a time 
sharing user is known to others. 


VM. Virtual Machine 


VM/370. Virtual Machine/370 A System Control 
Program 


VNET. (slang) Contraction of Vm NETworking, 
a programming RPQ that supported NJE on 
VM/370 systems. Predecessor to RSCS_ Net- 
working. Also the name of the IBM internal NJE 
network. 


VSE. Virtual Storage Extended. The successor to 
DOS/VS and DOS/VSE. 


VSE/POWER. “Virtual System Extended/Pnority 
Output Writers, Execution Processors and Input 


Readers”. A spooling system for VSE. 


VTAM. Virtual Telecommunications Access 
Method. A set of programs that control communi- 
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cation between terminals and application programs 
running under VSE, VM/SP3, and MVS. 


warm-start. The initialization of a system of sub- 
system that does not clean work out of the queues, 
but resumes processing of work previously left in 
the system. 
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workstation. A remote terminal connected to a 
host using RJE from which jobs can be submitted 
to the host for processing, and to which output can 
be returned. 


workstation program. A program residing in a 
subhost which acts like an RJE terminal. 


Index 


Special Characters 


$AJ 3-25, 3-36 
$CJ 3-25, 3-36 

$CL 3-35 

$CONNECT 2-11, 2-12, 2-28, 3-9 

$D 2-29, 3-14, 3-17, 3-20, 3-24 

$DF 3-17, 3-20 

$DJ 3-20, 3-36 

$DM_ 3-29, 3-36, 4-32 

$DMN_ 3-36 

$DN 3-17 

$DQ 3-17, 3-36 

$DU 3-8, 3-11 

$E 3-7, 3-11, 3-35 

$ELNE 3-7, 3-35 

$HJ 3-25, 3-36 

$LJ 3-20 

$MAXNODE 2-8 

$N 3-8, 3-14, 3-29, 3-30, 3-31, 3-33, 3-36, B-25, B-26, 
B-27, B-28 

$OJ 3-25 

$P 3-11, 3-25, 3-35, 3-36, B-3 

$PJ 3-25, 3-36 

$PJES2 3-7 

$PLGN 3-7 

$PLNE 3-7, 3-35 

$R 3-22, 3-24, 3-36 

$S 2-35, 2-36, 3-3, 3-4, 3-5, 3-6, 3-11, 3-13, 3-35, B-3 
$SL 2-35, 3-35 

$SN 2-33, 2-36, 2-37, 3-3, 3-4, 3-5, 3-6, 3-35, B-2, B-3, 
B-4 

$T 3-11, 3-18, 3-22, 3-25, 3-36 

$TJ 3-18, 3-25, 3-36 

$TN 3-8, 3-35 

$TOJ 3-18, 3-22, 3-25, 3-36 

$TR 3-35 

/*DEL 4-7 

/*EOF 4-7 

/*JOBPARM 2-9, 4-8, 4-9, 4-25 

/*NETACCT 2-30, 2-48, 4-7, 4-8, 4-16 

/*NOTIFY 2-13, 2-17, 4-7, 4-35 

/*OUTPUT 4-18, 4-19, 4-21, 4-24 

/*PRIORITY 4-7, 4-9 

/*PURGE 4-7 

/*ROUTE 4-5, 4-6, 4-7, 4-8, 4-9, 4-18, 4-21, 4-41 
/*SCAN 4-7 

/*SETUP 4-7 

/*XEQ 2-39, 4-5, 4-6, 4-8, 4-9, 4-31, 4-33, B-29, B-30 
/*XMIT 2-13, 2-39, 4-5, 4-6, 4-7, 4-8, 4-9, 4-10, 4-21 
// OUTPUT 4-18, 4-22 


//*FORMAT 4-22 
//*MAIN 2-9 
/*NETACCT 2-49, 4-12 
/*ROUTE 4-12 


ABEND _ 3-7 

ACB 2-11, 2-15, 2-35, 3-13, 3-35, B-2, B-3 

Accounting 1-1, 2-5, 2-40, 2-42, 2-47, 2-48, 2-49, 2-50, 
2-51, 2-52, 4-9, 4-10, D-4 

Accounting Record 2-48, 2-49, 2-50, 2-51 

ACF /VTAM _ 2-3, 2-4, 2-10, 2-15, 2-25, 4-42, A-11, 
C-1, C-2, D-1, D-4 

ACQ 2-34, 2-35, 2-36, A-7, A-12, A-15, A-17, A-19, 
B-18, B-19 

AFP 4-27, 4-28, B-8, B-10, D-1, D-2 

AFPDS_ B-8, D-1, D-2 

Algorithm 2-14, 2-40, 2-44, 3-12, 3-19, 3-35, B-19, 
B-20, B-21, D-2, D-6 

ALLOCATE 4-18, 4-22 

ALLUSERS 3-34 

Alter Node 

Alter Path 

Alternate Path 1-4, 2-12, 2-41 

Alternatives to NJE 1-6, 2-21 

AMS 2-15 

APAR 

See specific APARs, such as OZ81051 

APPL 2-11, 2-27, 2-30, 2-32, 2-33, 2-34, 2-35, 2-37, 
2-38, 3-3, 3-5, 3-13, 4-43, A-6, A-7, A-10, A-12, A-15, 
A-16, A-17, A-18, A-19, B-3, B-4, B-S, B-20, B-21 

Application 1-5, 1-6, 2-10, 2-24, 2-27, 2-30, 2-32, 2-33, 
2-34, 2-37, 2-45, 2-47, 3-13, A-7, A-9, A-12, A-15, 
A-17, A-18, B-2, B-3, B-4, B-5, B-18, B-19, B-20, B-21, 
C-5, D-4, D-7 

Applid 2-11, 2-27, 2-32, 2-33, 2-36, 3-3, 3-13, 3-35, 
A-6, A-7, A-16, A-18, B-3, B-4, B-S 

ATCCON = 2-32, 2-33, A-7, A-11, A-14, A-16, A-17 

ATCSTR = 2-32, 2-33, A-7, A-11, A-14, A-16, A-17 

Attach 1-1, 2-3, 2-4, 2-19, 2-29, 2-34, 2-42, 3-9, 3-11, 
3-13, 4-12, 4-27, B-7, B-9, B-10, D-1, D-3, D-6 

AUTH 2-34, A-5, A-7, A-12, A-15, A-16, A-17, A-19, 
B-20, B-21 

Authentication 2-15 

Authorization 2-13, 2-14, 2-15, 3-33, 3-34, 4-8, 4-9, 
4-18, D-6 

AUTOSTART 3-6 

Availability 2-3, 2-10, 2-19, 2-20, 2-21, 2-41, B-7 

Avoid 2-14, 2-26, 2-42, 2-43, 3-26, B-4 
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Back-bone 2-6 

BDT 1-4, 2-29, 2-35, 3-2, 3-4, 3-5, 3-17, 3-27, 3-36, 
4-41, 4-42, 4-43, 4-44, 4-45, A-9, A-10, B-18, B-29, 
C-4, D-1 

BDTRECV 4-41, 4-43 

BDTXMIT 4-41, 4-43 

BIND 2-32, 2-35, 2-36, 2-37, A-7, B-18, B-19, B-21, 
D-1 

BLDG 2-49 

BLKSIZE_  B-30 

Broadcast 3-14 

Buffer 2-19, 2-29, 2-37, 2-44, 2-46, 2-52, 3-31, A-2, 
A-7, A-10, B-2, B-6, B-12, B-13, B-14, B-15, B-23, 
B-24, B-25, D-6, D-7 

BUFNUM _ 2-29, B-3, B-12, B-14 

BUFSIZE 2-29, 2-36, 2-37, A-2, A-5, A-7, A-16, B-3, 
B-12, B-13, B-14, B-15 

BUFWARN_ 2-29 

Bulk Data 2-22, 4-39, 4-41, 4-42, B-29, D-1 

BURST 4-24 


Cancel 3-7, 3-16, 3-24, 3-25, 3-26, 3-29, 3-33, 3-35, 
3-36, 4-35, D-5 

Capacity 2-19, 2-44, B-2, B-4, B-5 

Carriage 4-40, B-8 

Catalog 4-16 

CDCINIT 2-35, 2-36, B-18, B-19 

CDINIT 2-35, 2-36, B-18, B-19, B-20 

CDRM _ 2-33, 2-34, A-6, A-7, A-11, A-14, A-17, A-19, 
B-5 

CDRSC_ 2-33, 2-34, A-7, A-11, A-14, A-17, A-19 

CHANGE _ 3-25, 3-34 

Checkpoint 2-22, 2-46, 4-44, 4-45, B-5 

CICS 2-8, 4-2, 4-17 

CKPTDEF A-18 

CLASS 4-22, 4-30 

Clock 2-7, 2-42, 2-47, 3-13, D-2 

CMD _ 3-30, 3-33, 3-36, 4-34 


CMS 2-23, 3-29, 4-2, 4-14, 4-22, 4-23, 4-29, 4-30, 4-32, 


4-34, 4-35, 4-36, 4-39, 4-41, 4-42, 4-43, 4-45, B-16, 
B-17, C-4, D-2 
Cold-start 2-26, 2-42, 2-43, D-2 
Command Authorization 2-15, 3-33 
Command Transmission 2-16, 4-4, 4-31 
See also Sending Commands 
COMPACT 2-30 
Compaction 1-4, 2-30, 2-38, 2-46, D-2 
Compatibility 2-24, 4-45, B-22 
Compression 2-30, 2-38, 2-52, D-2, D-6 
CONDEF 2-30, 4-33, A-18 
CONFIG 2-33, A-7, A-11, A-14, A-17 
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CONNECT 2-11, 2-27, 2-28, 2-38, 2-41, 2-42, 3-9, 
3-13, A-2, A-7 

Connection Problem 3-13 

Conversion 2-30, 3-22, 4-21 

COS 2-35, 2-36, 2-46, A-12, B-18, B-19 

Counterfeit 2-13 

CPQUERY 3-33 

Cryptographic 2-15, D-2 

CSALIMIT 2-33, A-11 

CTC 1-3, 1-4, 2-4, 2-10, 2-19, 2-21, 2-22, 2-24, 2-25, 
2-24, 2-26, 2-28, 2-29, 2-39, 2-41, 3-4, 3-5, 3-6, B-4, 
B-5, B-13, B-14, C-2, D-1, D-2, D-4 

Customization 2-2, 2-40, 2-49, 3-19, C-4 
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DALSUSER 4-18 

DALUSRID 4-18 

DASD 2-3, 2-21, D-4 

DATE 2-7 

DD 4-18, 4-19, 4-22, 4-31, 4-33, B-22, B-30 

Decryption 2-14 

DEFine 3-9 

Delay 2-29, 2-44, 2-46, D-6 

DELete 3-9 

Department 2-49, 2-52 

DEPT 2-49 

DES 2-13, 2-14, D-2 

DEST 2-30, 2-34, 3-17, 4-18, 4-19, 4-20, 4-21, 4-22, 
4-23, A-7 

DESTID 2-30, 4-19, 4-21 

DESTSA 2-34, A-7, A-12, A-15, A-17 

Dial 2-24, 2-41, 3-3, 4-43, D-5, D-7 

Directory 3-28 

Disable 3-19, 3-35 

Diskette 4-28 

DISOSS 4-2 

Distribution 4-4, 4-8, 4-17, 4-18, 4-20, 4-22, 4-24 

DLOGMOD 2-34, 2-37, A-7, A-12, A-15, A-17 

Drain 2-28, 3-7, 3-11, 3-12, 3-35, B-3, B-4 

DSN A-18, B-30 

DSX 2-22 

DUMMY 4-31, 4-33, B-30 

DUMP 4-42, 4-43 

Duplicate 3-26, D-2 
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Emulator 1-5, 2-4, 2-24 


Enable 1-1, 2-35, 3-3, 3-5, 3-11, 3-12, 3-13, 3-19, 3-35, 


4-41, D-4 
Encountering 3-26 
Encrypt 2-13, 2-14, 2-15, 2-17, 4-6, D-2 
EOJ 3-35 
EP 2-22, 2-24 


Errors 2-42, 4-10 

Execute 1-1, 1-2, 2-13, 2-14, 2-40, 2-48, 3-26, 3-27, 
3-28, 3-29, 4-6, 4-8, 4-12, 4-18, 4-22, 4-28, D-7 

Exit 2-2, 2-11, 2-13, 2-14, 2-15, 2-17, 2-22, 2-30, 2-31, 
2-35, 2-36, 2-39, 2-40, 2-48, 2-49, 3-19, 3-20, 3-33, 4-6, 
4-16, 4-29, 4-31, 4-35, 4-36, 4-37, 4-40, B-18, B-19, 
C-3, C-4 

Extensions 2-39 

External 2-39, 4-4, 4-17, 4-25, 4-39, 4-40 

External writer 2-39, 4-17, 4-25, 4-40 


Fan-out 4-19, D-2 
FCB 4-22, 4-24, 4-26, 4-28, B-9 
FIFO 3-15, 3-18, 3-19 
FILE 3-5, 3-20, 3-24, 3-36, 4-30, B-16 
File Transmission 4-4, 4-39, 4-42, 4-43 
FILEDEF 3-5 
Filename 4-14, 4-22, 4-30 
Filetype 4-14, 4-22, 4-30 
FLASH 4-22, 4-24, B-22 
FLUSH 3-34, 3-35 
FMH3_ 2-38 
FMH4 2-38 
FORCE | 3-7, 3-35 
FORM 4-22, 4-26, B-7, B-8, B-9, B-10, B-11 
Formatted commands 
See Global commands 
FORMDEF 4-26, B-7, B-8, B-9, B-10, B-11 
FREE 3-12 
FTF 3-8 
FTP 2-22, 4-39, 4-40, 4-41, 4-42, 4-43, 4-44, 4-45, C-5 


Gateway 2-5, 2-6, 2-15, 2-16, 2-17 

Global 3-20, 3-22, 3-24, 3-25, 3-29, 3-31, 3-33, 3-36, 
D-3 

Global Command 3-20, 3-22, 3-24, 3-31, 3-33 

GMT 2-7, 2-47, 3-13, D-2, D-3 

Greenwich 2-7, 2-47, D-3 
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HALT 3-7 

Hash 2-14 

Held Output 4-25, 4-29 

HOLD 3-12, 3-20, 3-26, 3-35, 3-36, 4-29 
HOSTSA 2-33, A-7, A-11, A-14, A-17 
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ICCF 3-28, 4-2, 4-23, 4-32, 4-34, 4-37 

Identification 2-13, 2-14, 2-32, 2-48, 4-9 

IDTF 4-40, 4-45 

IEBGENER §$ 4-31, 4-33, B-29, B-30 

IEBIMAGE § 4-28 

IEBPTPCH 4-12 

IEHMOVE $$ 4-39, 4-41, B-29, B-30 

IKJEF53 4-29 

IMAGELIB 4-28 

Immediate 1-6, 2-41, 3-7, 3-26, 3-35, 4-7, 4-9, D-7 

IMS 2-8 

INIT 3-5 

Initialization parameters 

See specific parameters, such as NJEDEF 

Initialize 2-7, 3-5, 3-13, B-26, B-27, B-28 

Initiator 4-16 

INQUIRY 3-8 

Interactive 1-6, 2-8, 2-39, 2-46, 3-30, 3-36, 4-4, 4-17, 
4-22, 4-23, 4-25, 4-29, 4-31, 4-39, 4-40, 4-43, 4-44, 
4-45, D-2, D-5 

Interfaces 2-27, 4-17 

Internal reader 2-31, 3-22, 4-2, 4-6, 4-7, 4-18, 4-20, 
4-31, 4-33, 4-41, B-24, B-29 

Interpret 3-20, 3-26, 4-21 

INTRDR_ 4-31, 4-33, B-30 

IOBUF 2-33, A-11 

IPL 2-7, 2-42 

ISTATUS 2-34, A-11 


JCT 2-39, 3-26, B-23, B-24, B-25, D-3 
JECL 2-39, 2-40, 2-48, 3-27, 4-5, 4-7, 4-10, 4-23, 4-35, 
D-3 
JESNEWS 4-27 
JES2 exit 2-14, 2-15, 2-17, 2-22, 2-30, 4-31 
JES2 initialization parameters 
See specific parameters, such as NJEDEF 
JES3 exit 4-29, 4-36 
Job Control 2-39, B-23, D-3 
Job copy 4-25 
Job execution 2-17, 4-3 
Job name 2-16, 3-20, 4-6, 4-12, 4-15 
Job number 2-30, 3-24, 4-15 
JOB Password 4-8 
Job Priority 4-9 
Job submission 4-5, 4-12, 4-14, 4-15, 4-44 
Job Tracking 3-15 
Job transmission 2-15, 2-44, 2-48, 2-50, 3-15, 3-17, 
3-18, 4-3, 4-5, 4-13, 4-35, 4-37 
JOBDEF 2-30, 2-42, 4-7, 4-9 
JOBID 4-15 
JOBNUM 2-42 
JOENUM 2-42 
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JRNUM 2-29, B-3 
JTNUM 2-29 
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Keyword 3-31, 4-22, A-15, B-11 


Latitude 2-30 

LDEST 4-23 

LGNS_ 3-8 

LGNI1 2-36, 3-3, 3-4, 3-5, B-3 

Limit 2-5, 2-8, 2-13, 2-21, 2-23, 2-46, 3-8, 3-31, 4-12, 
4-39, B-18 

LINE 2-26, 2-27, 2-29, 2-38, 3-8, 3-12, 3-13, 4-26, 
A-2, A-3, A-4, A-7, A-18, B-3, B-4 

Line Password 3-13 

LINECT 4-24 

LINEnnnn 2-26, 2-27, 2-29, B-4 

LINENUM 2-26, A-2, A-7, A-18, B-13 

LINK 2-7, 3-35, A-4, A-13, B-30 

LINKLIB_~ B-30 

LINKS 

Load 2-21, 2-35, 3-5, 3-10, 4-43, A-18, B-24, B-28, 
B-29, B-30 

LOADCMD _ 3-5 

LOCAL 2-7, 3-26, 4-20, A-4, A-5, A-13, A-16, B-16 


Logmode 2-32, 2-34, 2-35, 2-36, 2-37, 3-13, A-7, A-12, 


A-13, A-15, A-17, B-4, B-18, B-19, B-21 

LOGON 2-11, 2-15, 2-27, 2-30, 2-38, 3-8, 3-13, A-7, 
A-18, B-2, B-3, B-4, B-5, B-18, B-19 

LST 2-51, 2-52, 3-21, 3-36, 4-23 

LU 1-4, 2-8, 2-35, 2-36, 2-37, 3-5, A-10, A-13, B-2, 
B-4, B-18, D-4 

Luname_ 3-9, A-13 
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Mail 1-5, 2-23, 4-29, 4-39 
MAS | 1-6, 2-8, 2-9, 2-11, 2-21, 2-26, 2-28, 2-30, 2-38, 
2-42, 3-13, 3-31, B-5, D-4 
MASDEF 2-28, 3-13, B-5 
MASMSG_ 2-30 
MAXAPPL 2-33, A-11 
MAXOUT 2-46 
MAXSUBA 2-33, A-11 
MCS 3-31 
MEMBA_ 2-38, A-2, A-7 
MEMBB_ 2-38, A-2, A-7 
Message Transmission 2-16 
See also Sending Messages 
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Microfiche 1-5, 4-28 

Migration 1-5, 1-6 

MLU_ 2-29 

MODEENT 2-35, A-7, A-12, A-15, A-17, B-19 

Modems 2-15, 2-41, 3-13 

MODETAB 2-34, 2-35, 2-37, A-7, A-12, A-15, A-17, 
A-19, B-19 

Modification 2-8, 2-12, 2-13, 2-14, 2-16, 2-17, 2-27, 
2-28, 2-39, 2-40, 2-42, 2-44, 3-9, 4-42, 4-43, B-21, 
B-22, B-23, B-25, B-27, B-28, C-2, C-3 

Modify 2-12, 2-14, 2-16, 2-17, 2-40, 3-9, 3-33, B-3, 
B-18 

MODS 2-11, 2-12, 2-14, 4-31 

MODTAB 2-35 

MSG _ 3-30, 3-33, 3-34, 3-36, 4-29, 4-31, 4-32 

MSGCLASS 4-29, 4-31 

MSGHOLD 4-29 

MSNF_ 2-3, D-1, D-4 

Multi-access spool 2-9, 2-11, 2-38, 2-39, 2-42, 3-13, 
4-8, B-4, B-5S 

Multiple Transmitters 2-28, 2-37 

MVS/BDT _ 1-3, 1-4, 2-2, 2-8, 2-22, 2-25, 2-49, 2-51, 
3-2, 3-4, 3-8, 3-36, 4-36, 4-40, 4-44, 4-45, A-9, A-10, 
A-12, C-3 

MVS/XA_ 4-7, 4-18, B-6 


NAMES 4-32 
Naming 2-8, B-2 
NAT 2-29, 2-42, 3-13 
NATNUM = 2-29 
NCC 2-17, D-4, D-5 
NCP 2-3, 2-4, 2-34, 2-37, 2-46, A-6, D-4 
NDHGFLG1 4-24, 4-25, 4-29 
NDHGFIHD 4-25 
NDHGFILC 4-24 
NDHGFIOV 4-24, 4-25 
NDHGF2PR 4-25 
NDHGF2PU 4-25 
NDHGLNCT 4-24 
NDHGLREC 4-24 
NDHGRMT _ 3-27, 4-21 
NDT 2-35, 3-6, 3-10, 3-34, A-5, A-16 
NET 1-5, 2-30, 2-35, 2-37, 2-48, 2-51, 3-3, 3-5, 3-7, 
3-29, 3-33, 3-34, 3-35, 4-8, 4-12, 4-16, 4-31, 4-37, A-3, 
A-10, D-7 
NETACCT 2-30, 2-48, 4-8, 4-12, 4-16 
Netdata 2-40 
Network Access 2-15 
Network Boundaries 2-16 
Network Control 2-4, 3-3, 3-14, D-4 
Network Design 2-3, 2-23 
Network Device 3-11 
Network Implementation 2-24, 2-40 
Network Management 2-3, 2-41, 2-48, 2-52, 3-35 
Network path manager 
See Path manager 


Network Shut-Down 3-7 
Network Start 3-3 
NHDGFIHD 4-29 
Nicknames 4-32 
NJB 4-12 
NJE Features 1-4 
NJECONS | 3-4, A-3, A-10 
NJEDEF 2-26, 2-28, 2-29, 2-38, 2-42, A-2, A-7, A-18, 
B-3, B-6, B-13 
NJEROUT 3-22, 3-36 
NJESND = 3-17, 3-36 
NJHGACCT 2-52 
NJHGBLDG_ 2-52 
NJHGDEPT 2-52 
NJHGETS 2-45, 2-51 
NJHGJCPY 4-25 
NJHGJID 2-51 
NJHGJNAM | 2-51 
NJHGNPAS 2-14 
NJHGOGR_ 2-5] 
NJHGORGN 2-13, 2-17, 2-51 
NJHGORGQ 2-51, 4-12 
NJHGORGU 2-17 
NJHGPASS- 2-14 
NJHGPRGN 2-52 
NJHGPRIO 3-18, 3-19 
NJHGPRTN 2-52 
NJHGPRTR = 2-52 
NJHGPUNN_ 2-52 
NJHGPUNR_ 2-52 
NJHGROOM 2-52 
NJHGUSID 2-5] 
NJHGXEQN 2-51 
NJHGXEQU 2-51, 4-8 
NJTGALIN 2-52 
NJTGSTOP 2-45 
NJTGSTRT 2-45 
NMRDESC _ 3-31 
NMRFLAGT = 3-32, 4-32 
NMRFLAGW _ 3-32, 4-32 
NMRFMQUL . 3-31 
NMRLEVEL _ 3-31 
NMROUT _ 3-31 
NMRPRIO | 3-31 
NMRROUT _ 3-31 
NMRs | 1-2, 3-28, 3-29, 3-31, 4-4, 4-31 
NMRTOQUL _ 3-31, 4-12 
NMRUCM | 3-31 
Nnnn_ 2-8, 3-13, 3-20, 4-14, B-4, B-6 
Node Name_ 2-8, 2-47, 2-48 
Node Number 2-42 
Node Password 3-13 
Nodename 2-26, 2-51, 3-4, 3-6, 3-8, 3-12, 3-20, 3-30, 
4-5, 4-6, 4-8, 4-12, 4-18, 4-21, 4-30, B-3, D-5 
NODEnnnn_ 2-26, 2-27, 2-30 
NOH | 3-24, 3-35, 3-36, 4-14 
NOHEADER 4-14 
NOJOB 3-34 
NONETATH = 2-17 
NORCYV _ 3-12, 3-35 
NOTE 4-22, 4-25, 4-30, 4-32, 4-42 


Notification 2-39, 3-16, 3-28, 3-29, 4-7, 4-9, 4-35, 4-36, 
4-37, D-5 
NOTIFY 3-34, 4-9, 4-35 
NPM 1-2, 2-17, D-5 
See also Path manager 
NTFY 4-37 
NUMNODE 2-26 
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Offload 2-14, 2-41, 2-42, 4-8, B-24, B-26, B-27 

OPNDST 2-35, 2-36, B-18, B-20 

OPTCD 4-24, B-18 

ORDER 3-19, 3-36 

OUTCLASS 4-29 

OUTDEF 2-42 

OUTPUT 4-18, 4-19, 4-22, 4-29, 4-30, 4-33, 4-35, 
B-11 

Output Distribution 4-4, 4-17 

OVFL 4-24 

OWNNODE __s2-26, 2-38, 2-42, 2-43, A-2, A-7, A-18, 
B-3, B-6 

OY02269 4-10 

OY04055 4-35, 4-37 

OY04615 2-14, 4-8 

OYO05811 3-15 

OZ51862 4-10 

OZ53846 2-42 

OZ60994 2-48, 4-8 

OZ62754 2-42 

OZ65792 4-9 

OZ74692 4-6 

OZ76793 4-25 

OZ78140 4-25 

OZ81051 2-14, 4-8 

OZ84420 3-18 

OZ84814 4-35 

OZ85780 4-29 

OZ88264 4-10 

OZ93366 4-10 


P| 


PACCNT 2-49 

Pacing 2-19, 2-34, 2-35, 2-36, 2-37, 2-44, 2-46, B-2, 
B-4, B-5, B-18, B-19, B-20, B-21 

PACT 3-12, 3-35 

Page 2-37, 3-28, 4-24, 4-26, 4-27, 4-28, B-7, B-8, B-9, 
B-10, B-11, B-12, B-13, B-14, B-15, D-1, D-2, D-5 

Page-Mode 4-26, 4-27 

PAGEDEF 4-26, B-7, B-8, B-9, B-10, B-11 

PALTER 3-19, 3-23, 3-25, 3-34 

Parallel 1-4, 2-3, 2-10, 2-11, 2-41, 2-44, 3-11, D-5 

PARMLIB 2-7 

PARMTZ 2-7 


Index X-5 


Partitioned 2-4, 2-24, 4-40, 4-45, B-29 Punch 1-2, 1-5, 2-22, 2-31, 2-39, 2-49, 2-51, 2-52, 3-18, 


PASSCHK 2-14 3-20, 3-22, 3-27, 4-2, 4-14, 4-18, 4-20, 4-22, 4-23, 4-25, 
Password 2-13, 2-14, 2-15, 2-16, 2-48, 3-13, 4-6, 4-8, 4-28, 4-32, 4-42, 4-43, 4-44, B-16, B-17, D-7 

4-16, A-1, B-4, D-5 PUNNODE 2-52 

PATH 2-29, 2-32, 2-34, 3-9, 3-35, A-3, A-7, A-10, PUNODE 2-31, 4-20 

A-11, A-12, A-14, A-15, A-16, A-17, A-19, B-3 PUNTOUS 2-52 

Path manager 1-2, 2-7, 2-11, 2-12, 2-27, 2-28, 2-29, Purge 2-40, 2-48, 2-49, 2-51, 3-24, 3-25, 3-27, 3-28, 
2-42, 2-47, 3-9, D-2, D-4, D-5 3-34, 3-36, 4-7, D-2 

PBRDCST 3-30, 3-31, 3-34 Purges 3-25, 3-27, D-2 

PCANCEL _ 3-25, 3-34 PXMIT 3-25, 3-31 

PDELETE 3-25, 3-34 

PDEST 4-23 

PDISPLAY 3-9, 3-17, 3-21, 3-34, 3-36 

PDRAIN 3-12 | Q| 

PDS 4-40, B-30 

PEND 3-7 

Performance 2-3, 2-10, 2-19, 2-28, 2-37, 2-44, 2-46, QUERY 3-17, 3-20, 3-33, 3-36 

B-4, B-21, C-2 QUICK _ 3-7, 3-35 


Performance Management 2-44 
Performance Measurement 2-45 


PFLUSH 3-12 

PHOLD 3-19, 3-25, 3-34 R| 
PINQUIRE 3-9, 3-34 

Plan 2-2, 2-10, 2-13, 2-19, 2-26, 2-38, 2-40, 2-42, 2-49, 
3-19, B-7, C-1, C-3, C-4 

PLOAD 3-10, 3-35 

PLU 2-35, 2-36, B-3, B-18, B-19, B-20, B-21 


RACF 2-13, 2-14, 2-16, 2-17, 4-8, 4-16, 4-45 
RACINIT 2-14 

RACXTRT 2-14 

Range 2-30, 3-8, 3-20, D-2 


PNAME_ 2-49 
RCV 3-12, 3-35 
et ee 3-6, 3-7, 3-9, 3-10, 3-12, 3-34, 3-35, A-S, RDR 2-51, 3-21, 3-22, 3-36, 4-33 


RDRCHAR 4-33 

RDREXIT 2-40 

RDRLIST 4-30, 4-43 

READ 4-14, 4-42, 4-43, B-16 

READCARD 4-43 

READERnn_ 2-31, 4-6, 4-20 

Ready 3-25, D-1, D-4 

RECEIVE 4-22, 4-25, 4-29, 4-40, 4-43, B-22 

Receivers 2-17, 2-28, 2-29, 2-37, 2-46, 3-11, 3-12, 3-35, 
B-3, B-4, B-24 

Record length 4-10, 4-24, 4-30, 4-40, B-29 

Recovery 2-3, 2-10, 2-41, 3-26 

Redirect 3-22 

Reorder 3-36 

Requeue 3-26 

REROUTE | 3-10, 3-22 

Restart 2-28, 2-42, 3-7, 3-9, 3-1l 

RESTMAX 2-29, 2-41 

RESTNODE 2-29 

RESTTOL 2-29 

Rnnnn_ 2-31, 4-18, 4-20 

ROOM 2-49 

ROUTE | 3-9, 3-35, 4-12, A-4, A-13 

Routecodes 4-19 

ROUTES 3-35 

Routing Output 4-18, 4-22, 4-23 

RPL 2-37, B-12, B-13, B-14 

RSCS exit 

RTAM = 2-24 

RU 2-36, 2-37, A-12, A-15, B-18, B-19, D-6 


PNODE 3-10, A-5, A-16 

Port 2-5, 2-24, 2-26, 2-39, 3-5, B-16, D-4, D-7 

PRCVPAC 2-35, A-12 

PRDEST 4-20 

Predefined 2-11, B-18 

PRELEASE 3-19, 3-25, 3-34 

PRI 3-36, 4-18, 4-21, 4-22, 4-24, 4-42, 4-43, A-10 

PRINT 4-18, 4-21, 4-22, 4-24, 4-42, 4-43 

Printer 1-5, 2-22, 3-22, 3-28, 4-2, 4-17, 4-20, 4-22, 
4-23, 4-24, 4-25, 4-26, 4-27, 4-28, 4-42, B-7, B-8, B-9, 
B-10, B-11, D-1, D-5, D-7 

Priority 2-40, 2-44, 2-46, 3-14, 3-15, 3-18, 3-19, 3-25, 
4-7, 4-9, 4-10, B-2, B-19, D-3, D-5 

PRNODE 2-31, 4-20 

Problem Determination 3-13 

PROFILE 3-6 

PROFS 4-2, 4-30 

Propagate 2-13, 2-14, 2-28, 4-9 

Propagated 2-13, 2-14, 4-9 

Propagation 2-14, 2-17 

PRT 3-22, 4-7, 4-9, 4-22 

PRTY 4-7, 4-9 

PSF 4-26, 4-27, B-7, B-8, B-9, B-10, B-11, D-5 

PSNDPAC 2-35, A-12, A-15, A-17, B-19 

PSTART 3-6, 3-12 

PSTOP 3-7, 3-12 

PUDEST 4-20 

PUN 2-51, 3-21, 4-14, 4-18, 4-22, 4-23, 4-30, 4-32, 
4-42, 4-43, B-16, B-17 


X-6 JES2 NJE 


Ss 


Sample Network A-l 

Satellite 2-10, 2-19, 2-46 

Scheduler 2-44, D-6, D-7 

SDLC 2-3, 2-4, 2-10, 2-24, 2-41, B-2, B-4, B-5, D-6 

SDSF 3-17, 3-20, 4-29, 4-33, D-6 

Search 3-17, D-6 

Secondary 2-11, 2-21, 2-35, 2-36, 2-37, 2-39, 2-41, 
3-10, 4-15, 4-33, A-18, A-19, B-2, B-4, B-5, B-6, B-21 

Security 2-3, 2-5, 2-13, 2-14, 2-16, 2-21, 4-8, D-5, D-6 

SEND 2-23, 3-29, 4-22, 4-25, 4-29, 4-30, 4-31, 4-35, 
4-36, 4-42, 4-43, 4-44, 4-45, B-30 

SENDFILE 2-23, 4-22, 4-25, 4-29, 4-30, 4-35, 4-36, 
4-42, 4-43, 4-44, 4-45 

Sending Commands 3-29, 3-30, 3-31, 3-36, 4-33 

Sending Messages 3-29, 3-30, 3-31, 4-31 

SESSION = 2-29 

Session Establishment 2-35 

Session Initialization B-18 

SETUP 4-7 

SHARE 2-11, 2-12, 2-14, 4-31, B-26, B-28 

Shutdown 3-7, 3-35 

SID 2-28 

SIMLOGON - 2-35, B-18 

SLU 2-35, 2-36, B-3, B-18, B-19, B-20, B-21 

SMF _ 2-13, 2-42, 2-47, D-6 

SMF exit 2-13 

SMF record 2-7, 2-45, 2-46, 2-47, 2-49, 3-14, 3-26 

SMSG _ 3-30, 4-32, 4-34 

Source 2-15, 2-16, 2-35, 2-38, 3-31, 4-24, B-22, B-24, 
B-25, B-26, B-27, B-28 

Span 1-4, 2-7, 2-37, 2-47, 4-26, B-12, B-23 

Special Local 4-19 

SPL 2-26, 2-27, 2-28, B-6 

Splid 3-24, 3-36 

SPOOL 2-11, 2-42, 4-14, 4-22, 4-31, A-9, A-18, B-16, 
D-6, D-7 

Spool Offload 2-41, 2-42, B-26, B-27 

SPOOLDEF 2-42, A-18 

Spoolid 3-20, D-6 

SPOOLNUM 2-42 

SRNUM = 2-29 

SSCPID 2-33, A-11, A-14, A-17 

SSNDPAC 2-35, 2-36, 2-37, A-7, A-12, A-15, A-17, 
B-19, B-20, B-21 

SSOB_ 4-17 

START 2-35, 3-5, 3-12, 3-35 

STNUM — 2-29 

SUBAREA 2-34, A-7, A-11, A-14, A-17 

Subtract 1-2, 2-17, B-14, D-S5 

SVC 4-18 

Symbolic Destination 4-21 

SYNCTOL § 3-13 

SYSAFF 4-8 

SYSLOG 2-46, 3-14 

SYSTIME 2-7 


TAG 3-18, 4-14, 4-22, 4-23, 4-24, 4-42, B-16, B-17 

Tape 2-11, 2-12, 2-14, 2-23, 2-41, 4-31, 4-39, 4-41, 
B-29, B-30 

TELL 4-32 

Terminology 1-1, 1-2, 2-8 

Testing 1-5, 1-6, 2-4, 2-37, 2-39, A-18 

Threshold 2-29 

Time zone 2-7, 2-47 

TOD 2-7, 2-42, 2-47, 3-13, B-30, D-2 

Topology 2-3, A-7, D-5 

TPBF 2-29 

TPDEF 2-29, 2-36, 2-37, 2-38, A-2, A-7, B-3, B-12, 
B-13, B-14, B-15 

Trace 2-37, 3-35 

Traffic 1-2, 2-5, 2-6, 2-19, 2-29, 2-46, 2-47, B-2, B-4, 
B-5 

TRAN = 3-22, 3-24, 3-34, 3-36 

TRANSFER 3-22, 3-34 

Translation 3-18, 3-19, 3-20, 4-8, 4-16 

Transmission Priority 2-46 

Transmitter 2-17, 2-28, 2-29, 2-37, 2-39, 2-44, 2-45, 
2-46, 2-51, 3-11, 3-12, 3-26, 3-35, B-3, B-4, B-28 

Transparency 3-31, 4-10, 4-24 

TSO 2-8, 2-23, 2-31, 2-39, 3-20, 3-22, 3-25, 3-32, 4-2, 
4-6, 4-12, 4-18, 4-21, 4-22, 4-23, 4-25, 4-29, 4-30, 4-31, 
4-32, 4-33, 4-35, 4-36, 4-39, 4-40, 4-41, 4-43, 4-44, 
4-45, C-3, D-7 

TSO/E 2-39, 4-2, 4-6, 4-18, 4-22, 4-25, 4-29, 4-30, 
4-31, 4-35, 4-36, 4-39, 4-40, 4-43, 4-44, 4-45, C-3, D-7 

TYPE 2-33, 2-34, 3-12, A-3, A-4, A-7, A-10, A-11, 
A-12, A-13, A-14, A-15, A-17, A-19 


UCB 2-24 

UCS 4-28 

Unauthorized 2-13, 2-47 

Undefined Destination 3-26 

UNIT 2-27, 2-29, 4-16, A-2, A-7, A-18, B-3, B-4, B-30 
Unknown 3-26, 3-27, 3-28 

Unload 4-41, B-29, B-30 

User Identification 2-13, 2-48 

User sections 2-39, B-22, B-23, B-25, B-27 

Utilization 2-21, 2-28, 2-37, 2-44, 2-46, B-S 


Validation 2-14, 3-33, 4-6, 4-8 

VBUILD 2-33, 2-34, A-7, A-11, A-12, A-14, A-15, 
A-17, A-19 

Verification 2-13, 2-14, 4-6, 4-8, D-6 

VMSG 4-31, 4-42 


Index X-7 


VNET 1-5, D-7 
VPACING 2-34, 2-37, 2-46, A-7, A-12, A-15, A-17, 


A-19, B-20 
VSAM _ 4-42, 4-43, 4-45, B-29, B-30 
VTAM Parameters 2-32 XEQNODE 2-31 
VTAMLST 2-32, 2-34, 3-13, A-14 Xmit 2-45, 3-17, 3-25, 4-10, 4-12, 4-31 


XMT 3-17, 3-19, 3-21, 3-36 


Warm-start 2-8, 2-11, 2-12, 2-26, 2-42, D-8 
Workload 1-5, 1-6, 2-19, 2-29, 2-42 Zone 2-7, 2-46, 2-47 
Workstation 1-6, 2-8, 2-21, 2-22, 2-29, 3-24, 3-27, 
3-30, 4-4, 4-17, 4-18, 4-20, 4-32, 4-41, D-6, D-8 
WTR 3-20 : 
Numerics 


1Q5DI 4-37 

IRAOI 3-15, 4-37 

IRBSI 3-15, 4-37 

3088 2-4, 2-24, 2-39, D-2 

3800 1-5, 2-46, 4-24, B-7, B-9, B-28 
3820 4-26, B-7 
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